Midtier Issues Turn Into Gross BMC Incompetence

[Paul Blasquez]

Hello,

I'm a little upset here, as I have received instructions from BMC, that
had I carried them out blindly on my production server, would have
completely wiped out any workflow and data I had not backed up, and with
no warning from BMC.  I would like to share these instructions here, and
get opinions as to whether I am totally misunderstanding the
instructions, or if I was given incomplete and dangerous instructions by
an incompetent BMC tech.

The problem was, originally, that when my form was called from the
midtier via a table or results list, the browser would display the form
as blank even though a specific request id was requested.  So, double
click the ticket, window opens, form is blank instead of filled in with
that ticket's contents. All workflow works fine in the user client.

So, after minor troubleshooting with BMC they finally request the .def
file, I send it.

They get back to me with the following instructions (object name
replaced by FORM):

1. Go to the Admin tool and open that form FORM and Save as that form
with the different name e.g. FORM-new
2. Rename original form FORM to FORM-old  
3. Now rename FORM-new to FORM.
4. Delete the form FORM
5. Rename FORM-old to FORM
6. Verify all the Active Links/Filters point to FORM
7. Export the *.def file of FORM
8. Delete the form FORM
9. Create new form  name it FORM
10. Verify all the Active Links/Filter point to FORM


Now the issue with this, and thank goodness I did this on my development
server first, is that at step 8, YOU DESTROY ALL YOUR DATA AND WORKFLOW.

Making steps 9 and 10 irrelevant.

Even given the fact that I could have implied that at step 7 I should
have exported the entire workflow for that form, there is still no step
that says back up your data, and there are no steps explaining importing
back your workflow and data.

Please give me your points of view on this situation because I am trying
to not write a scathing email or make a hostile phone call right now.

Paul Blasquez
Senior Network Engineer/Remedy Developer | 
Desk - 408.360.5220 | 
Cell - 408.627.5714

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are

Re: Midtier Issues Turn Into Gross BMC Incompetence

[Kemes, Lisa]

They need a Step 4a: Make sure your company is equipped with a
defibrillator, as you will need this for coming back from a heart attack
from finding out that you've just deleted all your workflow 


Lisa

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 2:37 PM
To: arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence

Hello,

I'm a little upset here, as I have received instructions from BMC, that
had I carried them out blindly on my production server, would have
completely wiped out any workflow and data I had not backed up, and with
no warning from BMC.  I would like to share these instructions here, and
get opinions as to whether I am totally misunderstanding the
instructions, or if I was given incomplete and dangerous instructions by
an incompetent BMC tech.

The problem was, originally, that when my form was called from the
midtier via a table or results list, the browser would display the form
as blank even though a specific request id was requested.  So, double
click the ticket, window opens, form is blank instead of filled in with
that ticket's contents. All workflow works fine in the user client.

So, after minor troubleshooting with BMC they finally request the .def
file, I send it.

They get back to me with the following instructions (object name
replaced by FORM):

1. Go to the Admin tool and open that form FORM and Save as that form
with the different name e.g. FORM-new 2. Rename original form FORM
to FORM-old 3. Now rename FORM-new to FORM.
4. Delete the form FORM
5. Rename FORM-old to FORM
6. Verify all the Active Links/Filters point to FORM 7. Export the
*.def file of FORM 8. Delete the form FORM 9. Create new form  name
it FORM 10. Verify all the Active Links/Filter point to FORM


Now the issue with this, and thank goodness I did this on my development
server first, is that at step 8, YOU DESTROY ALL YOUR DATA AND WORKFLOW.

Making steps 9 and 10 irrelevant.

Even given the fact that I could have implied that at step 7 I should
have exported the entire workflow for that form, there is still no step
that says back up your data, and there are no steps explaining importing
back your workflow and data.

Please give me your points of view on this situation because I am trying
to not write a scathing email or make a hostile phone call right now.

Paul Blasquez
Senior Network Engineer/Remedy Developer | Desk - 408.360.5220 | Cell -
408.627.5714


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
Sponsor: www.rmsportal.com ARSlist: Where the Answers Are

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are

Re: Midtier Issues Turn Into Gross BMC Incompetence

[Rick Cook]

I would like to know why steps 3 and 5 are in there.  Why would one rename
two different forms to the same form name, even if that were possible?  Or
am I misunderstanding the process?

Rick

On Mon, Jun 2, 2008 at 11:37 AM, Paul Blasquez [EMAIL PROTECTED]
wrote:

 Hello,

 I'm a little upset here, as I have received instructions from BMC, that
 had I carried them out blindly on my production server, would have
 completely wiped out any workflow and data I had not backed up, and with
 no warning from BMC.  I would like to share these instructions here, and
 get opinions as to whether I am totally misunderstanding the
 instructions, or if I was given incomplete and dangerous instructions by
 an incompetent BMC tech.

 The problem was, originally, that when my form was called from the
 midtier via a table or results list, the browser would display the form
 as blank even though a specific request id was requested.  So, double
 click the ticket, window opens, form is blank instead of filled in with
 that ticket's contents. All workflow works fine in the user client.

 So, after minor troubleshooting with BMC they finally request the .def
 file, I send it.

 They get back to me with the following instructions (object name
 replaced by FORM):

 1. Go to the Admin tool and open that form FORM and Save as that form
 with the different name e.g. FORM-new
 2. Rename original form FORM to FORM-old
 3. Now rename FORM-new to FORM.
 4. Delete the form FORM
 5. Rename FORM-old to FORM
 6. Verify all the Active Links/Filters point to FORM
 7. Export the *.def file of FORM
 8. Delete the form FORM
 9. Create new form  name it FORM
 10. Verify all the Active Links/Filter point to FORM


 Now the issue with this, and thank goodness I did this on my development
 server first, is that at step 8, YOU DESTROY ALL YOUR DATA AND WORKFLOW.

 Making steps 9 and 10 irrelevant.

 Even given the fact that I could have implied that at step 7 I should
 have exported the entire workflow for that form, there is still no step
 that says back up your data, and there are no steps explaining importing
 back your workflow and data.

 Please give me your points of view on this situation because I am trying
 to not write a scathing email or make a hostile phone call right now.
 
 Paul Blasquez
 Senior Network Engineer/Remedy Developer |
 Desk - 408.360.5220 |
 Cell - 408.627.5714


 ___
 UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
 Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are

Re: Midtier Issues Turn Into Gross BMC Incompetence

[Lammey, Peter A.]

Wow.  This whole step by step procedure really has many issues:

1.  Why are they asking you to create copies and remove and replace the form on 
the server when this sounds like a Mid Tier issue not a server issue since you 
don't have the problem with the User client?  Wouldn't it have made sense to 
troubleshoot your issue with the mid tier cache or tomcat (or with whatever is 
hosting the web on your Mid Tier server)?

2.  Why would you be creating a separate iteration of the form and backing up 
the original form and then in addition to renaming the separate iteration to 
the name of the original form you would delete the original form and create the 
form from scratch?  It seems like they are having you do too many things at 
once.  Shouldn't they have you test one thing (seeing if it is an issue with 
the formname itself) and then if that does work try creating a form with that 
name from scratch to see if that resolves the issue?  Just not good advice to 
troubleshoot this issue (despite the fact that even the notion of 
troubleshooting a Mid Tier issue with rebuilding your form is crazy IMHO).

I would definitely escalate that issue to your BMC rep about this.

Thanks
Peter Lammey
ESPN MIT Technical Services  Applications Management
860-766-4761

-Original Message-
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 2:37 PM
To: arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence

Hello,

I'm a little upset here, as I have received instructions from BMC, that had I 
carried them out blindly on my production server, would have completely wiped 
out any workflow and data I had not backed up, and with no warning from BMC.  I 
would like to share these instructions here, and get opinions as to whether I 
am totally misunderstanding the instructions, or if I was given incomplete and 
dangerous instructions by an incompetent BMC tech.

The problem was, originally, that when my form was called from the midtier via 
a table or results list, the browser would display the form as blank even 
though a specific request id was requested.  So, double click the ticket, 
window opens, form is blank instead of filled in with that ticket's contents. 
All workflow works fine in the user client.

So, after minor troubleshooting with BMC they finally request the .def file, I 
send it.

They get back to me with the following instructions (object name replaced by 
FORM):

1. Go to the Admin tool and open that form FORM and Save as that form with 
the different name e.g. FORM-new 2. Rename original form FORM to FORM-old 
3. Now rename FORM-new to FORM.
4. Delete the form FORM
5. Rename FORM-old to FORM
6. Verify all the Active Links/Filters point to FORM 7. Export the *.def file 
of FORM 8. Delete the form FORM 9. Create new form  name it FORM 10. 
Verify all the Active Links/Filter point to FORM


Now the issue with this, and thank goodness I did this on my development server 
first, is that at step 8, YOU DESTROY ALL YOUR DATA AND WORKFLOW.

Making steps 9 and 10 irrelevant.

Even given the fact that I could have implied that at step 7 I should have 
exported the entire workflow for that form, there is still no step that says 
back up your data, and there are no steps explaining importing back your 
workflow and data.

Please give me your points of view on this situation because I am trying to not 
write a scathing email or make a hostile phone call right now.

Paul Blasquez
Senior Network Engineer/Remedy Developer | Desk - 408.360.5220 | Cell - 
408.627.5714

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: 
www.rmsportal.com ARSlist: Where the Answers Are

Please consider the environment before printing this e-mail.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are

Re: Midtier Issues Turn Into Gross BMC Incompetence

[LJ Longwing]

Yea...I can understand up to point 6but after that is just weird and
definitely shouldn't be done on a production server.

1. Go to the Admin tool and open that form FORM and Save as that form with
the different name e.g. FORM-new
2. Rename original form FORM to FORM-old (This is your actual
form...with data and stuff)
3. Now rename FORM-new to FORM. (this puts a blank form into place using
the original form name)
4. Delete the form FORM (removing blank form)
5. Rename FORM-old to FORM (rename original form from its new name to
its original name)
6. Verify all the Active Links/Filters point to FORM
7. Export the *.def file of FORM
8. Delete the form FORM
9. Create new form  name it FORM
10. Verify all the Active Links/Filter point to FORM
 

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 12:37 PM
To: arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence

Hello,

I'm a little upset here, as I have received instructions from BMC, that
had I carried them out blindly on my production server, would have
completely wiped out any workflow and data I had not backed up, and with
no warning from BMC.  I would like to share these instructions here, and
get opinions as to whether I am totally misunderstanding the
instructions, or if I was given incomplete and dangerous instructions by
an incompetent BMC tech.

The problem was, originally, that when my form was called from the
midtier via a table or results list, the browser would display the form
as blank even though a specific request id was requested.  So, double
click the ticket, window opens, form is blank instead of filled in with
that ticket's contents. All workflow works fine in the user client.

So, after minor troubleshooting with BMC they finally request the .def
file, I send it.

They get back to me with the following instructions (object name
replaced by FORM):

1. Go to the Admin tool and open that form FORM and Save as that form with
the different name e.g. FORM-new
2. Rename original form FORM to FORM-old  
3. Now rename FORM-new to FORM.
4. Delete the form FORM
5. Rename FORM-old to FORM
6. Verify all the Active Links/Filters point to FORM
7. Export the *.def file of FORM
8. Delete the form FORM
9. Create new form  name it FORM
10. Verify all the Active Links/Filter point to FORM


Now the issue with this, and thank goodness I did this on my development
server first, is that at step 8, YOU DESTROY ALL YOUR DATA AND WORKFLOW.

Making steps 9 and 10 irrelevant.

Even given the fact that I could have implied that at step 7 I should
have exported the entire workflow for that form, there is still no step
that says back up your data, and there are no steps explaining importing
back your workflow and data.

Please give me your points of view on this situation because I am trying
to not write a scathing email or make a hostile phone call right now.

Paul Blasquez
Senior Network Engineer/Remedy Developer | 
Desk - 408.360.5220 | 
Cell - 408.627.5714


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are

Re: Midtier Issues Turn Into Gross BMC Incompetence

[King, Rebecca (Mission Systems)]

I agree your instructions are incomplete although it's a basic rule that
when you delete a form all data goes with it.  Perhaps the tech
ass-u-me-d everyone knows this. 

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Kemes, Lisa
Sent: Monday, June 02, 2008 12:08 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

They need a Step 4a: Make sure your company is equipped with a
defibrillator, as you will need this for coming back from a heart attack
from finding out that you've just deleted all your workflow 


Lisa

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 2:37 PM
To: arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence

Hello,

I'm a little upset here, as I have received instructions from BMC, that
had I carried them out blindly on my production server, would have
completely wiped out any workflow and data I had not backed up, and with
no warning from BMC.  I would like to share these instructions here, and
get opinions as to whether I am totally misunderstanding the
instructions, or if I was given incomplete and dangerous instructions by
an incompetent BMC tech.

The problem was, originally, that when my form was called from the
midtier via a table or results list, the browser would display the form
as blank even though a specific request id was requested.  So, double
click the ticket, window opens, form is blank instead of filled in with
that ticket's contents. All workflow works fine in the user client.

So, after minor troubleshooting with BMC they finally request the .def
file, I send it.

They get back to me with the following instructions (object name
replaced by FORM):

1. Go to the Admin tool and open that form FORM and Save as that form
with the different name e.g. FORM-new 2. Rename original form FORM
to FORM-old 3. Now rename FORM-new to FORM.
4. Delete the form FORM
5. Rename FORM-old to FORM
6. Verify all the Active Links/Filters point to FORM 7. Export the
*.def file of FORM 8. Delete the form FORM 9. Create new form  name
it FORM 10. Verify all the Active Links/Filter point to FORM


Now the issue with this, and thank goodness I did this on my development
server first, is that at step 8, YOU DESTROY ALL YOUR DATA AND WORKFLOW.

Making steps 9 and 10 irrelevant.

Even given the fact that I could have implied that at step 7 I should
have exported the entire workflow for that form, there is still no step
that says back up your data, and there are no steps explaining importing
back your workflow and data.

Please give me your points of view on this situation because I am trying
to not write a scathing email or make a hostile phone call right now.

Paul Blasquez
Senior Network Engineer/Remedy Developer | Desk - 408.360.5220 | Cell -
408.627.5714


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
Sponsor: www.rmsportal.com ARSlist: Where the Answers Are


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are

Re: Midtier Issues Turn Into Gross BMC Incompetence

[strauss]

I have been having it out with support regularly this year, especially
over idiotic recommendations and faulty fixes (often to code that
never should have left the developer's workstation in the first place),
some of which would have had significant unintended consequences had I
been foolish enough to implement them in production. I too have trashed
a development server with at least one of them. It is all part of the
new improved BMC support structure, and is prevalent in _some_ support
areas (SLM, DSL) or if you don't get past the first-line folks overseas.
I am actually surprised that you got something so stupid on a mid-tier
problem, but I may have been lucky on who got my tickets. I see wild
variations between teams - ITSM 7 and RKM tickets have been getting
immediate and accurate responses this year so far, as have the ARS /
mid-tier / migratory issues so far.  Some of the overseas techs have
displayed remarkably little understanding of how data, workflow, and
forms reside in the database structure when they propose a workaround,
and that is probably what you got from someone.

If you look at your notifications from support, most of them now include
the direct email of the manager for that support team.  Write them. If
they do not respond, or if no manager reference is included in any of
the transactions for your issue, only then could you consider a
napalm-laden reply to the support tech. I guarantee that you will get
attention with that - unwanted attention, perhaps, but attention.  The
current support situation will bring out the worst in the most patient
person - and I have NEVER been accused of being a patient individual,
especially when faced with gross incompetence. My advice is to get to
the manager of the specific support person if you can; they need to take
action to preclude similar instances of unwise recommendations in the
future.

Christopher Strauss, Ph.D.
Call Tracking Administration Manager
University of North Texas Computing  IT Center
http://itsm.unt.edu/

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 1:37 PM
To: arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence

Hello,

I'm a little upset here, as I have received instructions from BMC, that
had I carried them out blindly on my production server, would have
completely wiped out any workflow and data I had not backed up, and with
no warning from BMC.  I would like to share these instructions here, and
get opinions as to whether I am totally misunderstanding the
instructions, or if I was given incomplete and dangerous instructions by
an incompetent BMC tech.

The problem was, originally, that when my form was called from the
midtier via a table or results list, the browser would display the form
as blank even though a specific request id was requested.  So, double
click the ticket, window opens, form is blank instead of filled in with
that ticket's contents. All workflow works fine in the user client.

So, after minor troubleshooting with BMC they finally request the .def
file, I send it.

They get back to me with the following instructions (object name
replaced by FORM):

1. Go to the Admin tool and open that form FORM and Save as that form
with the different name e.g. FORM-new
2. Rename original form FORM to FORM-old  
3. Now rename FORM-new to FORM.
4. Delete the form FORM
5. Rename FORM-old to FORM
6. Verify all the Active Links/Filters point to FORM
7. Export the *.def file of FORM
8. Delete the form FORM
9. Create new form  name it FORM
10. Verify all the Active Links/Filter point to FORM


Now the issue with this, and thank goodness I did this on my development
server first, is that at step 8, YOU DESTROY ALL YOUR DATA AND WORKFLOW.

Making steps 9 and 10 irrelevant.

Even given the fact that I could have implied that at step 7 I should
have exported the entire workflow for that form, there is still no step
that says back up your data, and there are no steps explaining importing
back your workflow and data.

Please give me your points of view on this situation because I am trying
to not write a scathing email or make a hostile phone call right now.

Paul Blasquez
Senior Network Engineer/Remedy Developer | 
Desk - 408.360.5220 | 
Cell - 408.627.5714


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are

Re: Midtier Issues Turn Into Gross BMC Incompetence

[Rick Cook]

I'm assuming that all instances of FORM refer to the same form and form
name.  So why would he, in step 3, rename FORM.old to FORM if in step 4,
FORM is just going to be deleted anyway?  If that's true, and if this entire
sequence has been accurately portrayed to us, it shows little thought or
experience.  I would deal with it at that level.

Rick

On Mon, Jun 2, 2008 at 12:15 PM, LJ Longwing [EMAIL PROTECTED] wrote:

 Yea...I can understand up to point 6but after that is just weird and
 definitely shouldn't be done on a production server.

 1. Go to the Admin tool and open that form FORM and Save as that form
 with
 the different name e.g. FORM-new
 2. Rename original form FORM to FORM-old (This is your actual
 form...with data and stuff)
 3. Now rename FORM-new to FORM. (this puts a blank form into place
 using
 the original form name)
 4. Delete the form FORM (removing blank form)
 5. Rename FORM-old to FORM (rename original form from its new name to
 its original name)
 6. Verify all the Active Links/Filters point to FORM
 7. Export the *.def file of FORM
 8. Delete the form FORM
 9. Create new form  name it FORM
 10. Verify all the Active Links/Filter point to FORM


 -Original Message-
 From: Action Request System discussion list(ARSList)
 [mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
 Sent: Monday, June 02, 2008 12:37 PM
 To: arslist@ARSLIST.ORG
 Subject: Midtier Issues Turn Into Gross BMC Incompetence

 Hello,

 I'm a little upset here, as I have received instructions from BMC, that
 had I carried them out blindly on my production server, would have
 completely wiped out any workflow and data I had not backed up, and with
 no warning from BMC.  I would like to share these instructions here, and
 get opinions as to whether I am totally misunderstanding the
 instructions, or if I was given incomplete and dangerous instructions by
 an incompetent BMC tech.

 The problem was, originally, that when my form was called from the
 midtier via a table or results list, the browser would display the form
 as blank even though a specific request id was requested.  So, double
 click the ticket, window opens, form is blank instead of filled in with
 that ticket's contents. All workflow works fine in the user client.

 So, after minor troubleshooting with BMC they finally request the .def
 file, I send it.

 They get back to me with the following instructions (object name
 replaced by FORM):

 1. Go to the Admin tool and open that form FORM and Save as that form
 with
 the different name e.g. FORM-new
 2. Rename original form FORM to FORM-old
 3. Now rename FORM-new to FORM.
 4. Delete the form FORM
 5. Rename FORM-old to FORM
 6. Verify all the Active Links/Filters point to FORM
 7. Export the *.def file of FORM
 8. Delete the form FORM
 9. Create new form  name it FORM
 10. Verify all the Active Links/Filter point to FORM


 Now the issue with this, and thank goodness I did this on my development
 server first, is that at step 8, YOU DESTROY ALL YOUR DATA AND WORKFLOW.

 Making steps 9 and 10 irrelevant.

 Even given the fact that I could have implied that at step 7 I should
 have exported the entire workflow for that form, there is still no step
 that says back up your data, and there are no steps explaining importing
 back your workflow and data.

 Please give me your points of view on this situation because I am trying
 to not write a scathing email or make a hostile phone call right now.
 
 Paul Blasquez
 Senior Network Engineer/Remedy Developer |
 Desk - 408.360.5220 |
 Cell - 408.627.5714


 
 ___
 UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
 Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are


 ___
 UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
 Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are

Re: Midtier Issues Turn Into Gross BMC Incompetence

[Gary Opela (Corporate)]

It almost sounds like he could have saved you a lot of time by saying:

1)   Export all active links, filters, menus, etc for FORM
2)   Copy FORM to FORM-A
3)   Delete FORM
4)   Rename FORM-A to FORM
5)   Re-import all active links, filters, menus, etc.

Even with that said, below are some issues you might face:
1)   Your new FORM will have a different schemaid, which would mess up any 
direct SQLs to that schema, as well as any DB Views you've created using it.
2)   I think the WF would re-attach to the form if it has the same name, I 
don't think this goes off of schemaid, but I'm not really sure about that.
3)   I still don't think this would solve the issue

Thank goodness you did this on Dev first. Is the issue occurring in both dev 
and production? If so, check the name of the form to make sure there isn't an 
issue with it.

Thanks,

Gary Opela, Jr., RSP
Remedy Engineer
Leader Communications, Inc.
http://www.5pointleader.com
http://www.lcibest.com
Best Product, Best People, Best PriceTM
An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company

From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Rick Cook
Sent: Monday, June 02, 2008 2:28 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

** I'm assuming that all instances of FORM refer to the same form and form 
name.  So why would he, in step 3, rename FORM.old to FORM if in step 4, FORM 
is just going to be deleted anyway?  If that's true, and if this entire 
sequence has been accurately portrayed to us, it shows little thought or 
experience.  I would deal with it at that level.

Rick
On Mon, Jun 2, 2008 at 12:15 PM, LJ Longwing [EMAIL PROTECTED]mailto:[EMAIL 
PROTECTED] wrote:
Yea...I can understand up to point 6but after that is just weird and
definitely shouldn't be done on a production server.

1. Go to the Admin tool and open that form FORM and Save as that form with
the different name e.g. FORM-new
2. Rename original form FORM to FORM-old (This is your actual
form...with data and stuff)
3. Now rename FORM-new to FORM. (this puts a blank form into place using
the original form name)
4. Delete the form FORM (removing blank form)
5. Rename FORM-old to FORM (rename original form from its new name to
its original name)
6. Verify all the Active Links/Filters point to FORM
7. Export the *.def file of FORM
8. Delete the form FORM
9. Create new form  name it FORM
10. Verify all the Active Links/Filter point to FORM

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Paul 
Blasquez
Sent: Monday, June 02, 2008 12:37 PM
To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence
Hello,

I'm a little upset here, as I have received instructions from BMC, that
had I carried them out blindly on my production server, would have
completely wiped out any workflow and data I had not backed up, and with
no warning from BMC.  I would like to share these instructions here, and
get opinions as to whether I am totally misunderstanding the
instructions, or if I was given incomplete and dangerous instructions by
an incompetent BMC tech.

The problem was, originally, that when my form was called from the
midtier via a table or results list, the browser would display the form
as blank even though a specific request id was requested.  So, double
click the ticket, window opens, form is blank instead of filled in with
that ticket's contents. All workflow works fine in the user client.

So, after minor troubleshooting with BMC they finally request the .def
file, I send it.

They get back to me with the following instructions (object name
replaced by FORM):

1. Go to the Admin tool and open that form FORM and Save as that form with
the different name e.g. FORM-new
2. Rename original form FORM to FORM-old
3. Now rename FORM-new to FORM.
4. Delete the form FORM
5. Rename FORM-old to FORM
6. Verify all the Active Links/Filters point to FORM
7. Export the *.def file of FORM
8. Delete the form FORM
9. Create new form  name it FORM
10. Verify all the Active Links/Filter point to FORM


Now the issue with this, and thank goodness I did this on my development
server first, is that at step 8, YOU DESTROY ALL YOUR DATA AND WORKFLOW.

Making steps 9 and 10 irrelevant.

Even given the fact that I could have implied that at step 7 I should
have exported the entire workflow for that form, there is still no step
that says back up your data, and there are no steps explaining importing
back your workflow and data.

Please give me your points of view on this situation because I am trying
to not write a scathing email or make a hostile phone call right now.

Paul Blasquez
Senior Network Engineer/Remedy Developer |
Desk - 408.360.5220 |
Cell - 408.627.5714

Re: Midtier Issues Turn Into Gross BMC Incompetence

[Paul Blasquez]

Yes you are correct, except that he renamed FORM.new to FORM, then
deleted it.
 
I believe he was attempting to, for lack of a better term, shake things
loose by running file writes on every conceivable storage location in
the backend.
 
The truly criminal step is step 8, as I said before.
 
And yes, this is a direct copy-paste from his emails to me.  Here is
another (referencing the current solution):
 
Did you tried the latest solution provided? it shouldn't cause any kind
of losss.
 
He states that because I had stated that it looked like I was going to
lose data.  I did not expect to also lose workflow.
 
 
Thank you everyone who replied confirming my conclusions.  I am
currently escalating with the manager provided at the bottom of his
email and our reseller.
 
-Paul



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Monday, June 02, 2008 12:28 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence


** I'm assuming that all instances of FORM refer to the same form and
form name.  So why would he, in step 3, rename FORM.old to FORM if in
step 4, FORM is just going to be deleted anyway?  If that's true, and if
this entire sequence has been accurately portrayed to us, it shows
little thought or experience.  I would deal with it at that level.

Rick


On Mon, Jun 2, 2008 at 12:15 PM, LJ Longwing [EMAIL PROTECTED]
wrote:


Yea...I can understand up to point 6but after that is just
weird and
definitely shouldn't be done on a production server.


1. Go to the Admin tool and open that form FORM and Save as
that form with
the different name e.g. FORM-new

2. Rename original form FORM to FORM-old (This is your
actual
form...with data and stuff)
3. Now rename FORM-new to FORM. (this puts a blank form into
place using
the original form name)
4. Delete the form FORM (removing blank form)
5. Rename FORM-old to FORM (rename original form from its
new name to
its original name)

6. Verify all the Active Links/Filters point to FORM
7. Export the *.def file of FORM
8. Delete the form FORM
9. Create new form  name it FORM
10. Verify all the Active Links/Filter point to FORM



-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez

Sent: Monday, June 02, 2008 12:37 PM
To: arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence


Hello,

I'm a little upset here, as I have received instructions from
BMC, that
had I carried them out blindly on my production server, would
have
completely wiped out any workflow and data I had not backed up,
and with
no warning from BMC.  I would like to share these instructions
here, and
get opinions as to whether I am totally misunderstanding the
instructions, or if I was given incomplete and dangerous
instructions by
an incompetent BMC tech.

The problem was, originally, that when my form was called from
the
midtier via a table or results list, the browser would display
the form
as blank even though a specific request id was requested.  So,
double
click the ticket, window opens, form is blank instead of filled
in with
that ticket's contents. All workflow works fine in the user
client.

So, after minor troubleshooting with BMC they finally request
the .def
file, I send it.

They get back to me with the following instructions (object name
replaced by FORM):

1. Go to the Admin tool and open that form FORM and Save as
that form with
the different name e.g. FORM-new
2. Rename original form FORM to FORM-old
3. Now rename FORM-new to FORM.
4. Delete the form FORM
5. Rename FORM-old to FORM
6. Verify all the Active Links/Filters point to FORM
7. Export the *.def file of FORM
8. Delete the form FORM
9. Create new form  name it FORM
10. Verify all the Active Links/Filter point to FORM


Now the issue with this, and thank goodness I did this on my
development
server first, is that at step 8, YOU DESTROY ALL YOUR DATA AND
WORKFLOW.

Making steps 9 and 10 irrelevant.

Even given the fact that I could have implied that at step 7 I
should
have exported the entire workflow for that form, there is still
no step
that says back up your data, and there are no steps explaining
importing
back your workflow and data.

Please give me your points of view on this situation because I

Re: Midtier Issues Turn Into Gross BMC Incompetence

[Paul Blasquez]

Yes, that actually sounds much more sane, and I do not have anything
built that is referencing schemaid.
 
This is happening in both dev and production, trying versions 6.3 and
7.1 of Midtier.  Both my dev and prod servers are:
 
Solaris 9
Oracle 9iR2
Arsystem 6.3 patch 22
 
I guess there is no reason not to share the form name, it is:
EQIX:SupportMain
 
I have several other forms with the EQIX: prefix that do not suffer from
this issue.
 
-Paul



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Gary Opela (Corporate)
Sent: Monday, June 02, 2008 12:46 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence


** 

It almost sounds like he could have saved you a lot of time by saying: 

 

1)   Export all active links, filters, menus, etc for FORM

2)   Copy FORM to FORM-A 

3)   Delete FORM 

4)   Rename FORM-A to FORM 

5)   Re-import all active links, filters, menus, etc.

 

Even with that said, below are some issues you might face:

1)   Your new FORM will have a different schemaid, which would mess
up any direct SQLs to that schema, as well as any DB Views you've
created using it.

2)   I think the WF would re-attach to the form if it has the same
name, I don't think this goes off of schemaid, but I'm not really sure
about that.

3)   I still don't think this would solve the issue

 

Thank goodness you did this on Dev first. Is the issue occurring in both
dev and production? If so, check the name of the form to make sure there
isn't an issue with it.

 

Thanks,

 

Gary Opela, Jr., RSP

Remedy Engineer

Leader Communications, Inc.

http://www.5pointleader.com

http://www.lcibest.com

Best Product, Best People, Best PriceTM

An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Monday, June 02, 2008 2:28 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

 

** I'm assuming that all instances of FORM refer to the same form and
form name.  So why would he, in step 3, rename FORM.old to FORM if in
step 4, FORM is just going to be deleted anyway?  If that's true, and if
this entire sequence has been accurately portrayed to us, it shows
little thought or experience.  I would deal with it at that level.

Rick

On Mon, Jun 2, 2008 at 12:15 PM, LJ Longwing [EMAIL PROTECTED]
wrote:

Yea...I can understand up to point 6but after that is just weird and
definitely shouldn't be done on a production server.


1. Go to the Admin tool and open that form FORM and Save as that form
with
the different name e.g. FORM-new

2. Rename original form FORM to FORM-old (This is your actual
form...with data and stuff)
3. Now rename FORM-new to FORM. (this puts a blank form into place
using
the original form name)
4. Delete the form FORM (removing blank form)
5. Rename FORM-old to FORM (rename original form from its new name
to
its original name)

6. Verify all the Active Links/Filters point to FORM
7. Export the *.def file of FORM
8. Delete the form FORM
9. Create new form  name it FORM
10. Verify all the Active Links/Filter point to FORM



-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez

Sent: Monday, June 02, 2008 12:37 PM
To: arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence

Hello,

I'm a little upset here, as I have received instructions from BMC, that
had I carried them out blindly on my production server, would have
completely wiped out any workflow and data I had not backed up, and with
no warning from BMC.  I would like to share these instructions here, and
get opinions as to whether I am totally misunderstanding the
instructions, or if I was given incomplete and dangerous instructions by
an incompetent BMC tech.

The problem was, originally, that when my form was called from the
midtier via a table or results list, the browser would display the form
as blank even though a specific request id was requested.  So, double
click the ticket, window opens, form is blank instead of filled in with
that ticket's contents. All workflow works fine in the user client.

So, after minor troubleshooting with BMC they finally request the .def
file, I send it.

They get back to me with the following instructions (object name
replaced by FORM):

1. Go to the Admin tool and open that form FORM and Save as that form
with
the different name e.g. FORM-new
2. Rename original form FORM to FORM-old
3. Now rename FORM-new to FORM.
4. Delete the form FORM
5. Rename FORM-old to FORM
6. Verify all the Active Links/Filters point to FORM
7. Export the *.def file of FORM
8. Delete the form FORM
9. Create new form  name it FORM
10. Verify all the Active Links/Filter point to FORM


Now the issue with this, and thank

Re: Midtier Issues Turn Into Gross BMC Incompetence

[Pierson, Shawn]

I love a good rant against BMC Support as much as the next person, but
I'd like to see your problem resolved too.

Can you give us more information that might help determine what the
problem is?  To start, are you using the Drill Down on the Table Field,
or are you trying to open that record with an Active Link?  If it's via
an Active Link, can you send us more information on the Open Window
command?

If I was in your shoes, I would run Active Link logs and try to
reproduce it in both the User Tool and on the Mid Tier, then compare
those log files and see what's happening.  My guess would be that
something potentially happens in one of those few areas where there is a
difference in the two, such as how Display/Windows Loaded for the
Execute On are different, or perhaps the timing works differently and
some workflow that has a lower execution order takes longer and a later
one does it's action first, or something weird.  Still, it should be
something you can figure out by looking at the logs from both.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 1:37 PM
To: arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence

Hello,

I'm a little upset here, as I have received instructions from BMC, that
had I carried them out blindly on my production server, would have
completely wiped out any workflow and data I had not backed up, and with
no warning from BMC.  I would like to share these instructions here, and
get opinions as to whether I am totally misunderstanding the
instructions, or if I was given incomplete and dangerous instructions by
an incompetent BMC tech.

The problem was, originally, that when my form was called from the
midtier via a table or results list, the browser would display the form
as blank even though a specific request id was requested.  So, double
click the ticket, window opens, form is blank instead of filled in with
that ticket's contents. All workflow works fine in the user client.

So, after minor troubleshooting with BMC they finally request the .def
file, I send it.

They get back to me with the following instructions (object name
replaced by FORM):

1. Go to the Admin tool and open that form FORM and Save as that form
with the different name e.g. FORM-new
2. Rename original form FORM to FORM-old
3. Now rename FORM-new to FORM.
4. Delete the form FORM
5. Rename FORM-old to FORM
6. Verify all the Active Links/Filters point to FORM
7. Export the *.def file of FORM
8. Delete the form FORM
9. Create new form  name it FORM
10. Verify all the Active Links/Filter point to FORM


Now the issue with this, and thank goodness I did this on my development
server first, is that at step 8, YOU DESTROY ALL YOUR DATA AND WORKFLOW.

Making steps 9 and 10 irrelevant.

Even given the fact that I could have implied that at step 7 I should
have exported the entire workflow for that form, there is still no step
that says back up your data, and there are no steps explaining importing
back your workflow and data.

Please give me your points of view on this situation because I am trying
to not write a scathing email or make a hostile phone call right now.

Paul Blasquez
Senior Network Engineer/Remedy Developer |
Desk - 408.360.5220 |
Cell - 408.627.5714


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are

Private and confidential as detailed here: 
http://www.sug.com/disclaimers/default.htm#Mail . If you cannot access the 
link, please e-mail sender.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are

Re: Midtier Issues Turn Into Gross BMC Incompetence

[Kaiser Norm E CIV USAF 96 CS/SCCE]

But if FORM has any records associated with it, copying FORM to FORM-A
will copy the form's layout and field structure, but the underlying
records won't go with it.  Thus, once you perform step 3, you lose all
your data.

I think the bottom line is, deleting forms to rectify a Midtier problem
is just plain dumb...it's like using a nuclear bomb when a bullet will
do.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Gary Opela (Corporate)
Sent: Monday, June 02, 2008 2:46 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

** 

It almost sounds like he could have saved you a lot of time by saying: 

 

1)   Export all active links, filters, menus, etc for FORM

2)   Copy FORM to FORM-A 

3)   Delete FORM 

4)   Rename FORM-A to FORM 

5)   Re-import all active links, filters, menus, etc.

 

Even with that said, below are some issues you might face:

1)   Your new FORM will have a different schemaid, which would mess
up any direct SQLs to that schema, as well as any DB Views you've
created using it.

2)   I think the WF would re-attach to the form if it has the same
name, I don't think this goes off of schemaid, but I'm not really sure
about that.

3)   I still don't think this would solve the issue

 

Thank goodness you did this on Dev first. Is the issue occurring in both
dev and production? If so, check the name of the form to make sure there
isn't an issue with it.

 

Thanks,

 

Gary Opela, Jr., RSP

Remedy Engineer

Leader Communications, Inc.

http://www.5pointleader.com

http://www.lcibest.com

Best Product, Best People, Best PriceTM

An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Monday, June 02, 2008 2:28 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

 

** I'm assuming that all instances of FORM refer to the same form and
form name.  So why would he, in step 3, rename FORM.old to FORM if in
step 4, FORM is just going to be deleted anyway?  If that's true, and if
this entire sequence has been accurately portrayed to us, it shows
little thought or experience.  I would deal with it at that level.

Rick

On Mon, Jun 2, 2008 at 12:15 PM, LJ Longwing [EMAIL PROTECTED]
wrote:

Yea...I can understand up to point 6but after that is just weird and
definitely shouldn't be done on a production server.


1. Go to the Admin tool and open that form FORM and Save as that form
with
the different name e.g. FORM-new

2. Rename original form FORM to FORM-old (This is your actual
form...with data and stuff)
3. Now rename FORM-new to FORM. (this puts a blank form into place
using
the original form name)
4. Delete the form FORM (removing blank form)
5. Rename FORM-old to FORM (rename original form from its new name
to
its original name)

6. Verify all the Active Links/Filters point to FORM
7. Export the *.def file of FORM
8. Delete the form FORM
9. Create new form  name it FORM
10. Verify all the Active Links/Filter point to FORM



-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez

Sent: Monday, June 02, 2008 12:37 PM
To: arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence

Hello,

I'm a little upset here, as I have received instructions from BMC, that
had I carried them out blindly on my production server, would have
completely wiped out any workflow and data I had not backed up, and with
no warning from BMC.  I would like to share these instructions here, and
get opinions as to whether I am totally misunderstanding the
instructions, or if I was given incomplete and dangerous instructions by
an incompetent BMC tech.

The problem was, originally, that when my form was called from the
midtier via a table or results list, the browser would display the form
as blank even though a specific request id was requested.  So, double
click the ticket, window opens, form is blank instead of filled in with
that ticket's contents. All workflow works fine in the user client.

So, after minor troubleshooting with BMC they finally request the .def
file, I send it.

They get back to me with the following instructions (object name
replaced by FORM):

1. Go to the Admin tool and open that form FORM and Save as that form
with
the different name e.g. FORM-new
2. Rename original form FORM to FORM-old
3. Now rename FORM-new to FORM.
4. Delete the form FORM
5. Rename FORM-old to FORM
6. Verify all the Active Links/Filters point to FORM
7. Export the *.def file of FORM
8. Delete the form FORM
9. Create new form  name it FORM
10. Verify all the Active Links/Filter point to FORM


Now the issue with this, and thank goodness I did this on my development
server first, is that at step 8, YOU DESTROY ALL YOUR

Re: Midtier Issues Turn Into Gross BMC Incompetence

[Paul Blasquez]

Thank you for the suggestions, unfortunately there is no smoking gun in
the logs.

It happens not only on a table drill down but also on a results list
drill down.  The only time it works as expected is when there is a
results list on top of the form, as in a standard search.  When you
highlight a ticket there, it populates the form underneath.  However, if
you double-click the same ticket from the same results list, the new
window fails to populate the data, and does not throw an error in either
the server or midtier logs.

BTW, I have finished importing my workflow and form back into
development from production and the issue still exists.  So, whatever
write operations he hoped would clear the issue obviously did not work,
as it has been blown away and restored and is still exhibiting the same
behavior.

-Paul

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Pierson, Shawn
Sent: Monday, June 02, 2008 1:15 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

I love a good rant against BMC Support as much as the next person, but
I'd like to see your problem resolved too.

Can you give us more information that might help determine what the
problem is?  To start, are you using the Drill Down on the Table Field,
or are you trying to open that record with an Active Link?  If it's via
an Active Link, can you send us more information on the Open Window
command?

If I was in your shoes, I would run Active Link logs and try to
reproduce it in both the User Tool and on the Mid Tier, then compare
those log files and see what's happening.  My guess would be that
something potentially happens in one of those few areas where there is a
difference in the two, such as how Display/Windows Loaded for the
Execute On are different, or perhaps the timing works differently and
some workflow that has a lower execution order takes longer and a later
one does it's action first, or something weird.  Still, it should be
something you can figure out by looking at the logs from both.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 1:37 PM
To: arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence

Hello,

I'm a little upset here, as I have received instructions from BMC, that
had I carried them out blindly on my production server, would have
completely wiped out any workflow and data I had not backed up, and with
no warning from BMC.  I would like to share these instructions here, and
get opinions as to whether I am totally misunderstanding the
instructions, or if I was given incomplete and dangerous instructions by
an incompetent BMC tech.

The problem was, originally, that when my form was called from the
midtier via a table or results list, the browser would display the form
as blank even though a specific request id was requested.  So, double
click the ticket, window opens, form is blank instead of filled in with
that ticket's contents. All workflow works fine in the user client.

So, after minor troubleshooting with BMC they finally request the .def
file, I send it.

They get back to me with the following instructions (object name
replaced by FORM):

1. Go to the Admin tool and open that form FORM and Save as that form
with the different name e.g. FORM-new
2. Rename original form FORM to FORM-old  
3. Now rename FORM-new to FORM.
4. Delete the form FORM
5. Rename FORM-old to FORM
6. Verify all the Active Links/Filters point to FORM
7. Export the *.def file of FORM
8. Delete the form FORM
9. Create new form  name it FORM
10. Verify all the Active Links/Filter point to FORM


Now the issue with this, and thank goodness I did this on my development
server first, is that at step 8, YOU DESTROY ALL YOUR DATA AND WORKFLOW.

Making steps 9 and 10 irrelevant.

Even given the fact that I could have implied that at step 7 I should
have exported the entire workflow for that form, there is still no step
that says back up your data, and there are no steps explaining importing
back your workflow and data.

Please give me your points of view on this situation because I am trying
to not write a scathing email or make a hostile phone call right now.

Paul Blasquez
Senior Network Engineer/Remedy Developer | 
Desk - 408.360.5220 | 
Cell - 408.627.5714


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are

Private and confidential as detailed here:
http://www.sug.com/disclaimers/default.htm#Mail . If you cannot access
the link, please e-mail sender.


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where

Re: Midtier Issues Turn Into Gross BMC Incompetence

[Pierson, Shawn]

I hate those types of issues and wish you good luck.  That sounds like a
problem with the core functionality, and the BMC support rep should have
involved Engineering by now.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 3:38 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

Thank you for the suggestions, unfortunately there is no smoking gun in
the logs.

It happens not only on a table drill down but also on a results list
drill down.  The only time it works as expected is when there is a
results list on top of the form, as in a standard search.  When you
highlight a ticket there, it populates the form underneath.  However, if
you double-click the same ticket from the same results list, the new
window fails to populate the data, and does not throw an error in either
the server or midtier logs.

BTW, I have finished importing my workflow and form back into
development from production and the issue still exists.  So, whatever
write operations he hoped would clear the issue obviously did not work,
as it has been blown away and restored and is still exhibiting the same
behavior.

-Paul

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Pierson, Shawn
Sent: Monday, June 02, 2008 1:15 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

I love a good rant against BMC Support as much as the next person, but
I'd like to see your problem resolved too.

Can you give us more information that might help determine what the
problem is?  To start, are you using the Drill Down on the Table Field,
or are you trying to open that record with an Active Link?  If it's via
an Active Link, can you send us more information on the Open Window
command?

If I was in your shoes, I would run Active Link logs and try to
reproduce it in both the User Tool and on the Mid Tier, then compare
those log files and see what's happening.  My guess would be that
something potentially happens in one of those few areas where there is a
difference in the two, such as how Display/Windows Loaded for the
Execute On are different, or perhaps the timing works differently and
some workflow that has a lower execution order takes longer and a later
one does it's action first, or something weird.  Still, it should be
something you can figure out by looking at the logs from both.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 1:37 PM
To: arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence

Hello,

I'm a little upset here, as I have received instructions from BMC, that
had I carried them out blindly on my production server, would have
completely wiped out any workflow and data I had not backed up, and with
no warning from BMC.  I would like to share these instructions here, and
get opinions as to whether I am totally misunderstanding the
instructions, or if I was given incomplete and dangerous instructions by
an incompetent BMC tech.

The problem was, originally, that when my form was called from the
midtier via a table or results list, the browser would display the form
as blank even though a specific request id was requested.  So, double
click the ticket, window opens, form is blank instead of filled in with
that ticket's contents. All workflow works fine in the user client.

So, after minor troubleshooting with BMC they finally request the .def
file, I send it.

They get back to me with the following instructions (object name
replaced by FORM):

1. Go to the Admin tool and open that form FORM and Save as that form
with the different name e.g. FORM-new
2. Rename original form FORM to FORM-old
3. Now rename FORM-new to FORM.
4. Delete the form FORM
5. Rename FORM-old to FORM
6. Verify all the Active Links/Filters point to FORM
7. Export the *.def file of FORM
8. Delete the form FORM
9. Create new form  name it FORM
10. Verify all the Active Links/Filter point to FORM


Now the issue with this, and thank goodness I did this on my development
server first, is that at step 8, YOU DESTROY ALL YOUR DATA AND WORKFLOW.

Making steps 9 and 10 irrelevant.

Even given the fact that I could have implied that at step 7 I should
have exported the entire workflow for that form, there is still no step
that says back up your data, and there are no steps explaining importing
back your workflow and data.

Please give me your points of view on this situation because I am trying
to not write a scathing email or make a hostile phone call right now.

Paul Blasquez
Senior Network Engineer/Remedy Developer |
Desk - 408.360.5220 |
Cell - 408.627.5714


___
UNSUBSCRIBE or access ARSlist Archives

Re: Midtier Issues Turn Into Gross BMC Incompetence

[Gary Opela (Corporate)]

I agree with Shawn, something deeper is amiss.
It sounds like a permissions issue -- where the user has permission to the 
form, but none of the fields. Unfortunately for you, if this where the issue, 
then you wouldn't have a results list with any data, or a table with any data, 
so this obviously isn't the issue.

Good luck with the fix, and PLEASE let us know what the issue was (even if it 
was something easy, then we all overlooked it).

Thanks,



Gary Opela, Jr., RSP

Remedy Engineer

Leader Communications, Inc.

http://www.5pointleader.com

http://www.lcibest.com

Best Product, Best People, Best PriceTM

An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company


-Original Message-
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Pierson, Shawn
Sent: Monday, June 02, 2008 3:40 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

I hate those types of issues and wish you good luck.  That sounds like a
problem with the core functionality, and the BMC support rep should have
involved Engineering by now.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 3:38 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

Thank you for the suggestions, unfortunately there is no smoking gun in
the logs.

It happens not only on a table drill down but also on a results list
drill down.  The only time it works as expected is when there is a
results list on top of the form, as in a standard search.  When you
highlight a ticket there, it populates the form underneath.  However, if
you double-click the same ticket from the same results list, the new
window fails to populate the data, and does not throw an error in either
the server or midtier logs.

BTW, I have finished importing my workflow and form back into
development from production and the issue still exists.  So, whatever
write operations he hoped would clear the issue obviously did not work,
as it has been blown away and restored and is still exhibiting the same
behavior.

-Paul

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Pierson, Shawn
Sent: Monday, June 02, 2008 1:15 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

I love a good rant against BMC Support as much as the next person, but
I'd like to see your problem resolved too.

Can you give us more information that might help determine what the
problem is?  To start, are you using the Drill Down on the Table Field,
or are you trying to open that record with an Active Link?  If it's via
an Active Link, can you send us more information on the Open Window
command?

If I was in your shoes, I would run Active Link logs and try to
reproduce it in both the User Tool and on the Mid Tier, then compare
those log files and see what's happening.  My guess would be that
something potentially happens in one of those few areas where there is a
difference in the two, such as how Display/Windows Loaded for the
Execute On are different, or perhaps the timing works differently and
some workflow that has a lower execution order takes longer and a later
one does it's action first, or something weird.  Still, it should be
something you can figure out by looking at the logs from both.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 1:37 PM
To: arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence

Hello,

I'm a little upset here, as I have received instructions from BMC, that
had I carried them out blindly on my production server, would have
completely wiped out any workflow and data I had not backed up, and with
no warning from BMC.  I would like to share these instructions here, and
get opinions as to whether I am totally misunderstanding the
instructions, or if I was given incomplete and dangerous instructions by
an incompetent BMC tech.

The problem was, originally, that when my form was called from the
midtier via a table or results list, the browser would display the form
as blank even though a specific request id was requested.  So, double
click the ticket, window opens, form is blank instead of filled in with
that ticket's contents. All workflow works fine in the user client.

So, after minor troubleshooting with BMC they finally request the .def
file, I send it.

They get back to me with the following instructions (object name
replaced by FORM):

1. Go to the Admin tool and open that form FORM and Save as that form
with the different name e.g. FORM-new
2. Rename original form FORM to FORM-old
3. Now rename FORM-new to FORM.
4. Delete the form FORM
5. Rename FORM-old to FORM
6. Verify all the Active Links/Filters point to FORM
7. Export the *.def

Re: Midtier Issues Turn Into Gross BMC Incompetence

[Paul Blasquez]

Hello All,

I am happy to report that within 5 minutes of getting a new support tech
my issue is resolved!

And it is so simple as to make my blood boil further from the previous
help I received.

The answer?

Under Form-Current View-Properties-Advanced Results List

Change No Selection to Select First, Fire Workflow. 

I don't know whether to be elated or tear out my hair or do the latter
in a joyous fashion. :)

-Paul



-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Gary Opela (Corporate)
Sent: Monday, June 02, 2008 1:48 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

I agree with Shawn, something deeper is amiss.
It sounds like a permissions issue -- where the user has permission to
the form, but none of the fields. Unfortunately for you, if this where
the issue, then you wouldn't have a results list with any data, or a
table with any data, so this obviously isn't the issue.

Good luck with the fix, and PLEASE let us know what the issue was (even
if it was something easy, then we all overlooked it).

Thanks,



Gary Opela, Jr., RSP

Remedy Engineer

Leader Communications, Inc.

http://www.5pointleader.com

http://www.lcibest.com

Best Product, Best People, Best PriceTM

An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Pierson, Shawn
Sent: Monday, June 02, 2008 3:40 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

I hate those types of issues and wish you good luck.  That sounds like a
problem with the core functionality, and the BMC support rep should have
involved Engineering by now.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 3:38 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

Thank you for the suggestions, unfortunately there is no smoking gun in
the logs.

It happens not only on a table drill down but also on a results list
drill down.  The only time it works as expected is when there is a
results list on top of the form, as in a standard search.  When you
highlight a ticket there, it populates the form underneath.  However, if
you double-click the same ticket from the same results list, the new
window fails to populate the data, and does not throw an error in either
the server or midtier logs.

BTW, I have finished importing my workflow and form back into
development from production and the issue still exists.  So, whatever
write operations he hoped would clear the issue obviously did not work,
as it has been blown away and restored and is still exhibiting the same
behavior.

-Paul

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Pierson, Shawn
Sent: Monday, June 02, 2008 1:15 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

I love a good rant against BMC Support as much as the next person, but
I'd like to see your problem resolved too.

Can you give us more information that might help determine what the
problem is?  To start, are you using the Drill Down on the Table Field,
or are you trying to open that record with an Active Link?  If it's via
an Active Link, can you send us more information on the Open Window
command?

If I was in your shoes, I would run Active Link logs and try to
reproduce it in both the User Tool and on the Mid Tier, then compare
those log files and see what's happening.  My guess would be that
something potentially happens in one of those few areas where there is a
difference in the two, such as how Display/Windows Loaded for the
Execute On are different, or perhaps the timing works differently and
some workflow that has a lower execution order takes longer and a later
one does it's action first, or something weird.  Still, it should be
something you can figure out by looking at the logs from both.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 1:37 PM
To: arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence

Hello,

I'm a little upset here, as I have received instructions from BMC, that
had I carried them out blindly on my production server, would have
completely wiped out any workflow and data I had not backed up, and with
no warning from BMC.  I would like to share these instructions here, and
get opinions as to whether I am totally misunderstanding the
instructions, or if I was given incomplete and dangerous instructions by
an incompetent BMC tech.

The problem was, originally, that when my form was called from the
midtier via a table or results list, the browser would display the form

Re: Midtier Issues Turn Into Gross BMC Incompetence

[Gary Opela (Corporate)]

Three cheers for new support tech for finding the simple solution!

I'll do the first...

Hip-Hip-Hooray!

Thanks,



Gary Opela, Jr., RSP

Remedy Engineer

Leader Communications, Inc.

http://www.5pointleader.com

http://www.lcibest.com

Best Product, Best People, Best PriceTM

An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company


-Original Message-
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 4:07 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

Hello All,

I am happy to report that within 5 minutes of getting a new support tech
my issue is resolved!

And it is so simple as to make my blood boil further from the previous
help I received.

The answer?

Under Form-Current View-Properties-Advanced Results List

Change No Selection to Select First, Fire Workflow.

I don't know whether to be elated or tear out my hair or do the latter
in a joyous fashion. :)

-Paul



-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Gary Opela (Corporate)
Sent: Monday, June 02, 2008 1:48 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

I agree with Shawn, something deeper is amiss.
It sounds like a permissions issue -- where the user has permission to
the form, but none of the fields. Unfortunately for you, if this where
the issue, then you wouldn't have a results list with any data, or a
table with any data, so this obviously isn't the issue.

Good luck with the fix, and PLEASE let us know what the issue was (even
if it was something easy, then we all overlooked it).

Thanks,



Gary Opela, Jr., RSP

Remedy Engineer

Leader Communications, Inc.

http://www.5pointleader.com

http://www.lcibest.com

Best Product, Best People, Best PriceTM

An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Pierson, Shawn
Sent: Monday, June 02, 2008 3:40 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

I hate those types of issues and wish you good luck.  That sounds like a
problem with the core functionality, and the BMC support rep should have
involved Engineering by now.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 3:38 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

Thank you for the suggestions, unfortunately there is no smoking gun in
the logs.

It happens not only on a table drill down but also on a results list
drill down.  The only time it works as expected is when there is a
results list on top of the form, as in a standard search.  When you
highlight a ticket there, it populates the form underneath.  However, if
you double-click the same ticket from the same results list, the new
window fails to populate the data, and does not throw an error in either
the server or midtier logs.

BTW, I have finished importing my workflow and form back into
development from production and the issue still exists.  So, whatever
write operations he hoped would clear the issue obviously did not work,
as it has been blown away and restored and is still exhibiting the same
behavior.

-Paul

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Pierson, Shawn
Sent: Monday, June 02, 2008 1:15 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

I love a good rant against BMC Support as much as the next person, but
I'd like to see your problem resolved too.

Can you give us more information that might help determine what the
problem is?  To start, are you using the Drill Down on the Table Field,
or are you trying to open that record with an Active Link?  If it's via
an Active Link, can you send us more information on the Open Window
command?

If I was in your shoes, I would run Active Link logs and try to
reproduce it in both the User Tool and on the Mid Tier, then compare
those log files and see what's happening.  My guess would be that
something potentially happens in one of those few areas where there is a
difference in the two, such as how Display/Windows Loaded for the
Execute On are different, or perhaps the timing works differently and
some workflow that has a lower execution order takes longer and a later
one does it's action first, or something weird.  Still, it should be
something you can figure out by looking at the logs from both.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 1:37 PM
To: arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence

Re: Midtier Issues Turn Into Gross BMC Incompetence

[David Sanders]

Hi Paul

Sounds like you're having fun... not.  Having got the form restored and
hopefully some sample data back in it, perhaps it's time to see whether
particular objects are causing the problem.

Try copying your main form View so you have a copy of your layout, then
remove all fields and trim objects from your main view (except one field)
and see if that will open up in the Mid-Tier.  Remember to flush the MT
cache.

It that works, move blocks of fields back into the view you are using and
test again until the problem recurs.  That way you may at least be able to
see what object is causing the Mid-Tier to choke.  I have seen strange MT
problems with images, navigation menus etc.

In the past when I have found the offending object, deleting and recreating
it has solved the issue.  If it is a data field you will need to plan how to
retain the data (by moving it into and from a temporary storage field?)

HTH

David Sanders
Remedy Solution Architect
Enterprise Service Suite @ Work
==
ARS List Award Winner 2005
Best 3rd party Remedy Application
 
See the ESS Concepts Guide
 
tel +44 1494 468980
mobile +44 7710 377761
email [EMAIL PROTECTED]
 
web http://www.westoverconsulting.co.uk
 

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 9:38 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

Thank you for the suggestions, unfortunately there is no smoking gun in
the logs.

It happens not only on a table drill down but also on a results list
drill down.  The only time it works as expected is when there is a
results list on top of the form, as in a standard search.  When you
highlight a ticket there, it populates the form underneath.  However, if
you double-click the same ticket from the same results list, the new
window fails to populate the data, and does not throw an error in either
the server or midtier logs.

BTW, I have finished importing my workflow and form back into
development from production and the issue still exists.  So, whatever
write operations he hoped would clear the issue obviously did not work,
as it has been blown away and restored and is still exhibiting the same
behavior.

-Paul

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Pierson, Shawn
Sent: Monday, June 02, 2008 1:15 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

I love a good rant against BMC Support as much as the next person, but
I'd like to see your problem resolved too.

Can you give us more information that might help determine what the
problem is?  To start, are you using the Drill Down on the Table Field,
or are you trying to open that record with an Active Link?  If it's via
an Active Link, can you send us more information on the Open Window
command?

If I was in your shoes, I would run Active Link logs and try to
reproduce it in both the User Tool and on the Mid Tier, then compare
those log files and see what's happening.  My guess would be that
something potentially happens in one of those few areas where there is a
difference in the two, such as how Display/Windows Loaded for the
Execute On are different, or perhaps the timing works differently and
some workflow that has a lower execution order takes longer and a later
one does it's action first, or something weird.  Still, it should be
something you can figure out by looking at the logs from both.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 1:37 PM
To: arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence

Hello,

I'm a little upset here, as I have received instructions from BMC, that
had I carried them out blindly on my production server, would have
completely wiped out any workflow and data I had not backed up, and with
no warning from BMC.  I would like to share these instructions here, and
get opinions as to whether I am totally misunderstanding the
instructions, or if I was given incomplete and dangerous instructions by
an incompetent BMC tech.

The problem was, originally, that when my form was called from the
midtier via a table or results list, the browser would display the form
as blank even though a specific request id was requested.  So, double
click the ticket, window opens, form is blank instead of filled in with
that ticket's contents. All workflow works fine in the user client.

So, after minor troubleshooting with BMC they finally request the .def
file, I send it.

They get back to me with the following instructions (object name
replaced by FORM):

1. Go to the Admin tool and open that form FORM and Save as that form
with the different name e.g. FORM-new
2. Rename original form FORM to FORM-old  
3. Now rename FORM-new to FORM.
4

Re: Midtier Issues Turn Into Gross BMC Incompetence

[LJ Longwing]

Have you looked in the mid-tier logs at the time that the client doesn't
show the window properly?  And just for completeness sake...Server and
Mid-Tier version and OS? 

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 2:38 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

Thank you for the suggestions, unfortunately there is no smoking gun in the
logs.

It happens not only on a table drill down but also on a results list drill
down.  The only time it works as expected is when there is a results list on
top of the form, as in a standard search.  When you highlight a ticket
there, it populates the form underneath.  However, if you double-click the
same ticket from the same results list, the new window fails to populate the
data, and does not throw an error in either the server or midtier logs.

BTW, I have finished importing my workflow and form back into development
from production and the issue still exists.  So, whatever write operations
he hoped would clear the issue obviously did not work, as it has been blown
away and restored and is still exhibiting the same behavior.

-Paul

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Pierson, Shawn
Sent: Monday, June 02, 2008 1:15 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

I love a good rant against BMC Support as much as the next person, but I'd
like to see your problem resolved too.

Can you give us more information that might help determine what the problem
is?  To start, are you using the Drill Down on the Table Field, or are you
trying to open that record with an Active Link?  If it's via an Active Link,
can you send us more information on the Open Window command?

If I was in your shoes, I would run Active Link logs and try to reproduce it
in both the User Tool and on the Mid Tier, then compare those log files and
see what's happening.  My guess would be that something potentially happens
in one of those few areas where there is a difference in the two, such as
how Display/Windows Loaded for the Execute On are different, or perhaps the
timing works differently and some workflow that has a lower execution order
takes longer and a later one does it's action first, or something weird.
Still, it should be something you can figure out by looking at the logs from
both.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
Sent: Monday, June 02, 2008 1:37 PM
To: arslist@ARSLIST.ORG
Subject: Midtier Issues Turn Into Gross BMC Incompetence

Hello,

I'm a little upset here, as I have received instructions from BMC, that had
I carried them out blindly on my production server, would have completely
wiped out any workflow and data I had not backed up, and with no warning
from BMC.  I would like to share these instructions here, and get opinions
as to whether I am totally misunderstanding the instructions, or if I was
given incomplete and dangerous instructions by an incompetent BMC tech.

The problem was, originally, that when my form was called from the midtier
via a table or results list, the browser would display the form as blank
even though a specific request id was requested.  So, double click the
ticket, window opens, form is blank instead of filled in with that ticket's
contents. All workflow works fine in the user client.

So, after minor troubleshooting with BMC they finally request the .def file,
I send it.

They get back to me with the following instructions (object name replaced by
FORM):

1. Go to the Admin tool and open that form FORM and Save as that form with
the different name e.g. FORM-new 2. Rename original form FORM to
FORM-old 3. Now rename FORM-new to FORM.
4. Delete the form FORM
5. Rename FORM-old to FORM
6. Verify all the Active Links/Filters point to FORM 7. Export the *.def
file of FORM 8. Delete the form FORM 9. Create new form  name it FORM
10. Verify all the Active Links/Filter point to FORM


Now the issue with this, and thank goodness I did this on my development
server first, is that at step 8, YOU DESTROY ALL YOUR DATA AND WORKFLOW.

Making steps 9 and 10 irrelevant.

Even given the fact that I could have implied that at step 7 I should have
exported the entire workflow for that form, there is still no step that says
back up your data, and there are no steps explaining importing back your
workflow and data.

Please give me your points of view on this situation because I am trying to
not write a scathing email or make a hostile phone call right now.

Paul Blasquez
Senior Network Engineer/Remedy Developer | Desk - 408.360.5220 | Cell -
408.627.5714


___
UNSUBSCRIBE or access ARSlist Archives