One idea might be to create an active link that displays a message box with $SERVER$ and $SERVERNAME$ in it so you can see what AR thinks there server is called and then base your escalation on that.
--- J.T. Shyman -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Pruitt, Christopher J Sent: Thursday, March 12, 2009 2:08 PM To: arslist@ARSLIST.ORG Subject: Re: Anyway to read the ARDBC via workflow? 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: christopher.pru...@eds.com 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:arsl...@arslist.org] On Behalf Of Grooms, Frederick W Sent: Thursday, March 12, 2009 12:43 PM To: arslist@ARSLIST.ORG 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:arsl...@arslist.org] On Behalf Of Pruitt, Christopher J Sent: Thursday, March 12, 2009 12:17 PM To: arslist@ARSLIST.ORG 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: christopher.pru...@eds.com -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Carey Matthew Black Sent: Thursday, March 12, 2009 11:57 AM To: arslist@ARSLIST.ORG 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 <christopher.pru...@eds.com> 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: christopher.pru...@eds.com _______________________________________________________________________________ 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"
