I know I've done something like this before but it may be that $SERVER$ isn't 
resolved in a Run If condition. If that is the case then you will need to 
create some kind of control form that sets a field to the server name and then 
checks it. Not sure how you could verify that easily...

--- 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:29 PM
To: arslist@ARSLIST.ORG
Subject: Re: Anyway to read the ARDBC via workflow?

Did that already. That is how I got the server name in the first place.

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 Shyman, Jonathan
Sent: Thursday, March 12, 2009 1:09 PM
To: arslist@ARSLIST.ORG
Subject: Re: Anyway to read the ARDBC via workflow?

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"

_______________________________________________________________________________
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"

Reply via email to