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 ): 1. Go to the Admin tool and open that form and Save as that form with the different name e.g. -new 2. Rename original form to -old 3. Now rename -new to . 4. Delete the form 5. Rename -old to 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to 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
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 ): 1. Go to the Admin tool and open that form and Save as that form with the different name e.g. -new 2. Rename original form to -old 3. Now rename -new to . 4. Delete the form 5. Rename -old to 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to 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
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 ): > > 1. Go to the Admin tool and open that form and Save as that form > with the different name e.g. -new > 2. Rename original form to -old > 3. Now rename -new to . > 4. Delete the form > 5. Rename -old to > 6. Verify all the Active Links/Filters point to > 7. Export the *.def file of > 8. Delete the form > 9. Create new form & name it > 10. Verify all the Active Links/Filter point to > > > 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
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 ): 1. Go to the Admin tool and open that form and Save as that form with the different name e.g. -new 2. Rename original form to -old 3. Now rename -new to . 4. Delete the form 5. Rename -old to 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to 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
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 and Save as that form with the different name e.g. -new 2. Rename original form to -old (This is your actual form...with data and stuff) 3. Now rename -new to . (this puts a blank form into place using the original form name) 4. Delete the form (removing blank form) 5. Rename -old to (rename original form from its new name to its original name) 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to -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 ): 1. Go to the Admin tool and open that form and Save as that form with the different name e.g. -new 2. Rename original form to -old 3. Now rename -new to . 4. Delete the form 5. Rename -old to 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to 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
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 ): 1. Go to the Admin tool and open that form and Save as that form with the different name e.g. -new 2. Rename original form to -old 3. Now rename -new to . 4. Delete the form 5. Rename -old to 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to 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
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 ): 1. Go to the Admin tool and open that form and Save as that form with the different name e.g. -new 2. Rename original form to -old 3. Now rename -new to . 4. Delete the form 5. Rename -old to 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to 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
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 and Save as that form > with > the different name e.g. -new > 2. Rename original form to -old (This is your actual > form...with data and stuff) > 3. Now rename -new to . (this puts a blank form into place > using > the original form name) > 4. Delete the form (removing blank form) > 5. Rename -old to (rename original form from its new name to > its original name) > 6. Verify all the Active Links/Filters point to > 7. Export the *.def file of > 8. Delete the form > 9. Create new form & name it > 10. Verify all the Active Links/Filter point to > > > -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 ): > > 1. Go to the Admin tool and open that form and Save as that form > with > the different name e.g. -new > 2. Rename original form to -old > 3. Now rename -new to . > 4. Delete the form > 5. Rename -old to > 6. Verify all the Active Links/Filters point to > 7. Export the *.def file of > 8. Delete the form > 9. Create new form & name it > 10. Verify all the Active Links/Filter point to > > > 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
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 and Save as that form with the different name e.g. -new 2. Rename original form to -old (This is your actual form...with data and stuff) 3. Now rename -new to . (this puts a blank form into place using the original form name) 4. Delete the form (removing blank form) 5. Rename -old to (rename original form from its new name to its original name) 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Paul Blasquez Sent: Monday, June 02, 2008 12:37 PM To: arslist@ARSLIST.ORG<mailto: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 ): 1. Go to the Admin tool and open that form and Save as that form with the different name e.g. -new 2. Rename original form to -old 3. Now rename -new to . 4. Delete the form 5. Rename -old to 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to 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
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 and Save as that form with the different name e.g. -new 2. Rename original form to -old (This is your actual form...with data and stuff) 3. Now rename -new to . (this puts a blank form into place using the original form name) 4. Delete the form (removing blank form) 5. Rename -old to (rename original form from its new name to its original name) 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to -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 ): 1. Go to the Admin tool and open that form and Save as that form with the different name e.g. -new 2. Rename original form to -old 3. Now rename -new to . 4. Delete the form 5. Rename -old to 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to 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
Re: Midtier Issues Turn Into Gross BMC Incompetence
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 and Save as that form with the different name e.g. -new 2. Rename original form to -old (This is your actual form...with data and stuff) 3. Now rename -new to . (this puts a blank form into place using the original form name) 4. Delete the form (removing blank form) 5. Rename -old to (rename original form from its new name to its original name) 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to -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 ): 1. Go to the Admin tool and open that form and Save as that form with the different name e.g. -new 2. Rename original form to -old 3. Now rename -new to . 4. Delete the form 5. Rename -old to 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to Now the issue with this, and thank goodness I did this on my development server
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 ): 1. Go to the Admin tool and open that form and Save as that form with the different name e.g. -new 2. Rename original form to -old 3. Now rename -new to . 4. Delete the form 5. Rename -old to 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to 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
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 and Save as that form with the different name e.g. -new 2. Rename original form to -old (This is your actual form...with data and stuff) 3. Now rename -new to . (this puts a blank form into place using the original form name) 4. Delete the form (removing blank form) 5. Rename -old to (rename original form from its new name to its original name) 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to -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 ): 1. Go to the Admin tool and open that form and Save as that form with the different name e.g. -new 2. Rename original form to -old 3. Now rename -new to . 4. Delete the form 5. Rename -old to 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to 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 st
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 ): 1. Go to the Admin tool and open that form and Save as that form with the different name e.g. -new 2. Rename original form to -old 3. Now rename -new to . 4. Delete the form 5. Rename -old to 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to 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.r
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 ): 1. Go to the Admin tool and open that form and Save as that form with the different name e.g. -new 2. Rename original form to -old 3. Now rename -new to . 4. Delete the form 5. Rename -old to 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to 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
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 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 ): 1. Go to the Admin tool and open that form and Save as that form with the different name e.g. -new 2. Rename original form to -old 3. Now rename -new to . 4. Delete the form 5. Rename -old to 6. Verify all the Active Links/Filters point to 7. Export the *.def fi
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 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 t
Re: Midtier Issues Turn Into Gross BMC Incompetence
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 P
Re: Midtier Issues Turn Into Gross BMC Incompetence
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 ): 1. Go to the Admin tool and open that form and Save as that form with the different name e.g. -new 2. Rename original form to -old 3. Now rename -new
Re: Midtier Issues Turn Into Gross BMC Incompetence
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 ): 1. Go to the Admin tool and open that form and Save as that form with the different name e.g. -new 2. Rename original form to -old 3. Now rename -new to . 4. Delete the form 5. Rename -old to 6. Verify all the Active Links/Filters point to 7. Export the *.def file of 8. Delete the form 9. Create new form & name it 10. Verify all the Active Links/Filter point to 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 Spo