Chris,
Since you are obviously having issues with the $SERVER$ identification within the escalation, I was wondering if there was something else that you could use as a qualifier (even if it isn't as clean). Just as a test, you could modify the qualification for your production server to say $DATE$ > "1/1/70" (which it will always be) and on your dev server set it up as $DATE$ < "1/1/70". Obviously, this is ugly and a BAD way to get one to fire and one not but if you need it done quickly, it will work until you can debug the $SERVER$ issue. You just need to remember to change the qualification in your def or xml file prior to migration. Scott Illari 908-601-8948 <http://www.linkedin.com/in/scottillari> http://www.linkedin.com/in/scottillari From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Pruitt, Christopher J Sent: Thursday, March 12, 2009 3:33 PM To: [email protected] Subject: Re: Anyway to read the ARDBC via workflow? ** Yea, I think there is a bug with the escalator. I set the Run if to $SERVER$ LIKE "%FOOFIGHTER" and the escalation still fired. Christopher Pruitt Consultant Specialist EDS, an HP Company mailto: [email protected] We deliver on our commitments so you can deliver on yours. Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Juan Ingles Sent: Thursday, March 12, 2009 2:24 PM To: [email protected] Subject: Re: Anyway to read the ARDBC via workflow? ** Chris, It seems like there has to be something wrong with the qualification. As you can see from the responses, plenty of people use $SERVER$ for this exact type of thing. Usually the only hurdle is figuring out exactly what $SERVER$ returns. (short name vs long name, etc.) Can you show us the entire qualification you are using? Also, for fun and giggles, have you tried printing $SERVER$ on your dev machine to make absolute sure that it doesn't match? Juan Ingles On Thu, Mar 12, 2009 at 11:29 AM, Pruitt, Christopher J <[email protected]> wrote: Yea, already did that as well. The server name I am using is correct. I have triple checked it. Christopher Pruitt Consultant Specialist EDS, an HP Company mailto: [email protected] We deliver on our commitments so you can deliver on yours. Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Carey Matthew Black Sent: Thursday, March 12, 2009 1:12 PM To: [email protected] Subject: Re: Anyway to read the ARDBC via workflow? Christopher, Have an escalation do a Set field action and put the SERVER keyword in a field. Turn on Filter and Escalation logs and verify that the value you see there is the value you were using. -- Carey Matthew Black BMC Remedy AR System Skilled Professional (BRSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On Thu, Mar 12, 2009 at 1:07 PM, Pruitt, Christopher J <[email protected]> wrote: > Yes, very sure. The actual server name is prod01 and we enter $SERVER$ = "prod01" but the escalation on the testing servers runs every time regardless what we put in there. I have not tried the LIKE statement as in your example. But I am willing to try anything at this point. > > Christopher Pruitt > Consultant Specialist > EDS, an HP Company > mailto: [email protected] > > We deliver on our commitments > so you can deliver on yours. > > Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. > > > -----Original Message----- > From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Grooms, Frederick W > Sent: Thursday, March 12, 2009 12:43 PM > To: [email protected] > Subject: Re: Anyway to read the ARDBC via workflow? > > Are you sure you put the sever name in exactly like the server thinks it's name is? i.e. server is "foo" and you entered "FOO" > > We routinely have escalations with qualifications like: > $SERVER$ like "dev%" > or > $SERVER$ like "prd%" > > Fred > > -----Original Message----- > From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Pruitt, Christopher J > Sent: Thursday, March 12, 2009 12:17 PM > To: [email protected] > Subject: Re: Anyway to read the ARDBC via workflow? > > Not sure why, we tried it and it just ignored it. Ran on the test servers anyway. > > Christopher Pruitt > Consultant Specialist > EDS, an HP Company > mailto: [email protected] > > -----Original Message----- > From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Carey Matthew Black > Sent: Thursday, March 12, 2009 11:57 AM > To: [email protected] > Subject: Re: Anyway to read the ARDBC via workflow? > > Christopher, > > Maybe I am missing something here, but why would ($ SERVER$ = "FOO" OR > $ SERVER$ = "BAR") not work for this? > > -- > Carey Matthew Black > BMC Remedy AR System Skilled Professional (BRSP) > ARS = Action Request System(Remedy) > > Love, then teach > Solution = People + Process + Tools > Fast, Accurate, Cheap.... Pick two. > > > > On Thu, Mar 12, 2009 at 11:51 AM, Pruitt, Christopher J > <[email protected]> wrote: >> ** >> >> Hello Fellow Listers, >> >> >> >> I am attempting to find some way to read the >> REMEDY.ARDBC.SERVER.ADMINISTRATION table Server Info Form via an >> escalation. What we are attempting to do is to set an escalation to run only >> when it is on Server A but not when it is on Server B. The reason this is >> important is we have an escalation that turn on API and SQL logging at set >> time and a second escalation that turns the logs back off after several >> hours. This is needed to capture information after hours when the users are >> not on the system. >> >> >> >> We can turn on and off these logs for the System Administration: Server >> Information form all the time without issue. Here is our problem. Our DBAs >> take a Oracle Cold Backup of the server once a month and then place that on >> our testing servers to allow our testing team the ability to test with the >> most up-to-date data possible. However, the issue is when the DBAs do that >> the active escalations that turns on and off these log files are now running >> on the testing servers, which is what we do not want to happen. So what we >> have to do is to manually disable them on those testing servers every time >> or our log space gets filled up very quickly (which is not monitored by our >> on call members, unlike Production which is). >> >> >> >> So we have tossed around the idea of creating a control form to hold the >> Server Name but really don't want to go there if there is an easier way. We >> tried to use the Server field off of the AR System Administration: Server >> Information form in the Run If for the escalation like $SERVER$ = "Server >> A" but that did not work either. Seems like that field only displays the >> server name but does not retain it. >> >> >> >> So any ideas on how I can determine in an escalation which server it is >> running on so it will only run on Server A and not Server B, C, etc.? >> >> >> >> >> >> We have the following configuration. >> >> >> >> AR System 7.1 >> >> Oracle 10.2 64-bit >> >> SunOS 5.9 >> >> Christopher Pruitt >> Consultant Specialist >> EDS, an HP Company >> mailto: [email protected] > > ____________________________________________________________________________ ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" > > ____________________________________________________________________________ ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" > > ____________________________________________________________________________ ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" > > ____________________________________________________________________________ ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" > ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
