Re: Open question to BMC on troubleshooting without the WUT

[Walters, Mark]

I'd suggest using the driver or JavaDriver utility that is included with the 
server.  You can script this to login and issue any API call - you also get the 
option to set the RPC queue so you could create a test that logs and tests 
several different queues in case you're just using up all of one thread type.

Mark

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of William Rentfrow
Sent: 16 October 2014 18:02
To: arslist@ARSLIST.ORG
Subject: Open question to BMC on troubleshooting without the WUT

**
I sent this to our premiere support person and manager, but I'd be interested 
to see what others have to say about this too.

Original message below:

Hi -

This came up on our call and I wanted to write it out.

BMC has stated that the Windows User Tool (WUT) is going to be discontinued (in 
fact, it already was in 7.6x).  What I need to  know is what is BMC's 
recommendation for diagnosing problems with the AR Servers in a server group?

Currently our users will report an issue like this: "Remedy is slow/locked 
up/whatever".  Routinely we get no more information than this.

Right now our troubleshooting is to first diagnose which server(s) is having 
problems.  The fast way to do this is to login to every server with the user 
tool.  We usually know within a few seconds if one of the AR servers is locked 
up, because we will not be able to log in to it.  Then we can bounce it and get 
service restored.

If they are responsive we then move on the Mid-tier servers, etc.

With a large load-balanced environment there is no way to QUICKLY do this 
without the WUT.  I could login with Developer Studio, but that doesn't use the 
same threads on the server as the WUT does.  We have seen instances where users 
are locked up and admins can log in with Dev studio (and vice versa).  Same 
goes for migrator and the import tool.

Support suggesting checking the AR Error log, but there are two problems with 
that - first, many lock-up scenarios do not results in errors in the 
arerror.log file.  There are numerous other logs to check on every server as 
well (CMDB, Email, AIE, etc).  Checking every log file on every server is time 
consuming and not 100% guaranteed to show us which server is locked up.

The second problem with support's suggestion is the sheer time it would take to 
login to each server.  We are on Linux, so we need to connect via SSH using 
putty.  We do that by first connecting to a gateway server.  Then we ssh to the 
actual AR server (direct access is not allowed).  Finally, we sudo to the user 
Remedy is running as.  That means each time we connect it's 3X we login.  If we 
multiply that by the 10 servers in our server group it would take at least an 
hour just to triage the problem.

I can do the same thing with the WUT in seconds.

So here is the question: What is the proper way to QUICKLY triage which server 
is having problems without using the WUT or Dev Studio/Migrator/Import?

William Rentfrow

_ARSlist: "Where the Answers Are" and have been for 20 years_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Open question to BMC on troubleshooting without the WUT

[Larry Robinson]

Thanks John... I'll certainly pass that on.
Larry

On Fri, Oct 17, 2014 at 1:26 AM, John Baker 
wrote:

> Larry
>
> I wouldn't suggest using that JSP :) It is running a native application
> (hostname) to get the hostname that is readily available from a Java API
> call.
>
> Running native applications isn't going to do the performance of your Mid
> Tier any good, and anyone with a copy of wget can almost certainly kill
> your Mid Tier pretty quickly.
>
> The Java InetAddress API is what you should be using for this task.
>
>
> John
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Screen Shot

[Tanner, Doug]

Looking for a Screen shot of a Successful CMDB 8.1.02 install. Anyone have one?
Thanks, Doug
(SHARE:Application Properties)
[cid:image001.png@01CFE9F4.2B66E790]

This email is subject to certain disclaimers, which may be reviewed via the 
following link. http://compass-usa.com/Pages/Disclaimer.aspx.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Screen Shot

[Pierson, Shawn]

This isn't my production system, it's my QA system that is mostly the same as 
my production system (except that the Help documentation has never been updated 
in years apparently.)  We actually ran into no issues with it when upgrading 
from Atrium Core 8.1.

[cid:image002.png@01CFE9EC.BADE53C0]

Thanks,

Shawn Pierson
Remedy Developer | Energy Transfer

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Tanner, Doug
Sent: Friday, October 17, 2014 9:22 AM
To: arslist@ARSLIST.ORG
Subject: Screen Shot

**
Looking for a Screen shot of a Successful CMDB 8.1.02 install. Anyone have one?
Thanks, Doug
(SHARE:Application Properties)
[cid:image003.png@01CFE9EC.BADE53C0]

This email is subject to certain disclaimers, which may be reviewed via the 
following link. http://compass-usa.com/Pages/Disclaimer.aspx.
_ARSlist: "Where the Answers Are" and have been for 20 years_

Private and confidential as detailed here: 
http://www.energytransfer.com/mail_disclaimer.aspx .  If you cannot access the 
link, please e-mail sender.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Screen Shot

[Tanner, Doug]

Thanks Shawn, Doug

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Pierson, Shawn
Sent: Friday, October 17, 2014 10:29 AM
To: arslist@ARSLIST.ORG
Subject: Re: Screen Shot

**
This isn't my production system, it's my QA system that is mostly the same as 
my production system (except that the Help documentation has never been updated 
in years apparently.)  We actually ran into no issues with it when upgrading 
from Atrium Core 8.1.

[cid:image001.png@01CFE9F5.C9A1D7C0]

Thanks,

Shawn Pierson
Remedy Developer | Energy Transfer

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Tanner, Doug
Sent: Friday, October 17, 2014 9:22 AM
To: arslist@ARSLIST.ORG
Subject: Screen Shot

**
Looking for a Screen shot of a Successful CMDB 8.1.02 install. Anyone have one?
Thanks, Doug
(SHARE:Application Properties)
[cid:image002.png@01CFE9F5.C9A1D7C0]

This email is subject to certain disclaimers, which may be reviewed via the 
following link. http://compass-usa.com/Pages/Disclaimer.aspx.
_ARSlist: "Where the Answers Are" and have been for 20 years_
Private and confidential as detailed 
here. If you cannot access 
hyperlink, please e-mail sender.
_ARSlist: "Where the Answers Are" and have been for 20 years_
This email is subject to certain disclaimers, which may be reviewed via the 
following link. http://compass-usa.com/Pages/Disclaimer.aspx.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Set Field If syntax when matching on another form

[Rick Westbrock]

Hi all-

I wanted to get feedback on something I remember learning way back in a Remedy 
class (pre-BMC) in Pleasanton to make sure that I am remembering correctly. I 
seem to recall that I was told that the best practice when writing the 
qualification for a Set Fields action from another form that you should use the 
other form's field before the operator and the current form's field after the 
operator like this: 'DEPTID' = $DeptID-New$

I thought that this was either more efficient or provided more predictable 
results (or maybe both). Does anyone else follow this convention? I have run 
across several instances in some custom workflow where that is reversed and I 
see $DeptID-New$ = 'DEPTID' which just feels wrong to me. Below is more detail 
to clarify my examples.

Form A: field DeptID-New
Form B: field DEPTID

There is a filter on form A that does a set fields which reads its value from 
form B. I believe the proper syntax if I want to match the department ID fields 
between the forms is this:
'DEPTID' = $DeptID-New$

>From there the set fields action can copy values from the matching record in 
>form B into the fields of form A.


Thanks,
Rick

_
Rick Westbrock
AppOps Engineer | IT Department
24 Hour Fitness USA, Inc.



___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Set Field If syntax when matching on another form

[Tanner, Doug]

Rick, I am not sure if there is any performance gain, but I always go to the 
database first. Doug

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock
Sent: Friday, October 17, 2014 10:35 AM
To: arslist@ARSLIST.ORG
Subject: Set Field If syntax when matching on another form

**
Hi all-

I wanted to get feedback on something I remember learning way back in a Remedy 
class (pre-BMC) in Pleasanton to make sure that I am remembering correctly. I 
seem to recall that I was told that the best practice when writing the 
qualification for a Set Fields action from another form that you should use the 
other form's field before the operator and the current form's field after the 
operator like this: 'DEPTID' = $DeptID-New$

I thought that this was either more efficient or provided more predictable 
results (or maybe both). Does anyone else follow this convention? I have run 
across several instances in some custom workflow where that is reversed and I 
see $DeptID-New$ = 'DEPTID' which just feels wrong to me. Below is more detail 
to clarify my examples.

Form A: field DeptID-New
Form B: field DEPTID

There is a filter on form A that does a set fields which reads its value from 
form B. I believe the proper syntax if I want to match the department ID fields 
between the forms is this:
'DEPTID' = $DeptID-New$

>From there the set fields action can copy values from the matching record in 
>form B into the fields of form A.


Thanks,
Rick

_
Rick Westbrock
AppOps Engineer | IT Department
24 Hour Fitness USA, Inc.

_ARSlist: "Where the Answers Are" and have been for 20 years_
This email is subject to certain disclaimers, which may be reviewed via the 
following link. http://compass-usa.com/Pages/Disclaimer.aspx.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: ENGAGE 2014 Commentary

[Adams, Peter]

Currently (version 1.0) we have designed for and tested the Remedy with Smart 
IT native app only for tablets (Android & iOS,  7'' and higher screen size).
Given the smartphone screens are typically smaller, we plan to rearrange some 
of the screens for the smartphone version of the app that should come out not 
too far out.

Peter Adams
Principal Product Manager


-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Pierson, Shawn
Sent: Wednesday, October 15, 2014 11:20 AM
To: arslist@ARSLIST.ORG
Subject: Re: ENGAGE 2014 Commentary

I'm curious about your comment, " An iPhone/Android phone app is also in the 
pipeline."  I thought it was already out, just not on the app stores yet?

I know next to nothing about iOS (and don't like it, personally) but in looking 
through the SmartIT zip files, which I haven't had a chance to install yet, 
I've MyIT.apk and Smart_IT.apk.  I may load them up in an android emulator and 
see if they do anything if I have free time this week.

Thanks,

Shawn Pierson 
Remedy Developer | Energy Transfer


-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Blairing
Sent: Wednesday, October 15, 2014 12:29 PM
To: arslist@ARSLIST.ORG
Subject: Re: ENGAGE 2014 Commentary

Yes, it WAS. Sat in the front row... With a box lunch... Just behind the 
audience mic, and I didn't want to munch my salad for all of you to hear. :-)

Not sure how much of the pageantry in the room was sent live to the net, but I 
can vouch that the demos on the iPad were indeed on the iPad on stage, and 
another person typed the responses live. The idea of being able to do the bar 
code read from your iPad (finally! Someone has done this!) ranks high in my 
list. After the demos there was a panel taking live questions from the 
audience, they're out in the hallway still talking to some.

I got a chance to be a beta tester for future versions of SmartIT (one of the 
session rooms is a testing lab). Sorry, no details to post. But it was a very 
cool experience to have some input into the design process.

The more I see of SmartIT, the more I am convinced that this is the logical 
next phase of the client, with the potential to make the current web clients go 
away. The framework is flexible, adaptable, taking advantage of the devices we 
all carry around anyway, using their built in capabilities (maps for example) 
as one would naturally expect. As of today there are three different "personas" 
for which the SmartIT client has been designed, but there are more on the way. 
An iPhone/Android phone app is also in the pipeline. Very excited about this

Back to more sessions now

Doug

--
Doug Blair
+1 224-558-5462

Sent from my iPad Air
Auto-corrected typos, misspellings and non-sequiturs are gratefully attributed 
to Steve Jobs :-)

> On Oct 15, 2014, at 11:10 AM, Shellman, David  wrote:
> 
> Yes
> 
> -Original Message-
> From: Action Request System discussion list(ARSList) 
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe D'Souza
> Sent: Wednesday, October 15, 2014 11:04 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: ENGAGE 2014 Commentary
> 
> Is that the launch that will be streamed live on video?
> 
> Cheers
> 
> Joe
> 
> 
> -Original Message-
> From: Action Request System discussion list(ARSList) 
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Blairing
> Sent: Wednesday, October 15, 2014 9:01 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: ENGAGE 2014 Commentary
> 
> I love it. Hawaiian shirts in Florida is "serious."
> 
> Today is intense. No morning keynote, right into sessions at 8:00 AM, with 
> the SmartIT launch in 3 hours. Be sure to watch! For what it's worth, I've 
> seen some material which amounts to a preview of the launch, and it will be 
> worth getting your managers to watch!
> 
> Doug
> 
> --
> Doug Blair
> +1 224-558-5462
> 
> Sent from my iPad Air
> Auto-corrected typos, misspellings and non-sequiturs are gratefully 
> attributed to Steve Jobs :-)
> 
>> On Oct 14, 2014, at 10:30 PM, arslist  wrote:
>> 
>> As long as we are dealing with serious stuff, Thursday is declared
> official
>> Hawaii shirt day for those that brought them, since there is no WWRUG
> Award
>> session and that would normally be Thursday.
>> 
>> Just had a tremendous, if not quite organized, evening with 
>> engineering in which I had my first serious question in years 
>> answered! They were still going strong at almost 10pm.
>> 
>> Also, DISCLAIMER: Note, those twinkies have BMC logos on them, they 
>> are
> not
>> the Canadian Twinkies, I did not bring them, nor did I throw or 
>> condone
> the
>> throwing of them at a time that many were not prepared or expecting them.
> I
>> wholeheartedly support the concept, but a heads up first would have 
>> been a good part of the process. Then those that didn't know what to 
>> expect could of turned to those of us in the know and

Re: Set Field If syntax when matching on another form

[LJ LongWing]

Rick,
This is one of my personal pet peeves.  I started learning database and
Remedy around the same time, and all of the instruction that I ever
received in the database, and what makes most sense to me is

field = value

This translates in a remedy world to

'Field' = $Value$

So, from this convention, I always use it as you state you prefer.  Over
the years, I have found TONS of different contractors that come and go use

$Value$ = 'Field'

and while I don't believe it causes any performance impact in any way to do
it that way, it's visually unappealing to me...it took me awhile, but I
eventually figured out WHY some developers produce code that looks like
that.  It has to do how things show up in the drop down in the Dev Studio.
When building a setfield action, or push for that matter I think, when
selecting fields, 'Current Form' is always the 'default', and current form
is the one that produces $Value$, where 'form that it's being selected
from' is not the defaultso, what you get is the developer selecting the
field on the current form first, and the 'other' form second, which builds a

$Value$ = 'Field'

type of qualificationso, while I don't think it causes any problems,
it's certainly not visually appealing to me...and I agree with you that it
'should be' the other way.

On Fri, Oct 17, 2014 at 8:34 AM, Rick Westbrock 
wrote:

> **
>
> Hi all-
>
>
>
> I wanted to get feedback on something I remember learning way back in a
> Remedy class (pre-BMC) in Pleasanton to make sure that I am remembering
> correctly. I seem to recall that I was told that the best practice when
> writing the qualification for a Set Fields action from another form that
> you should use the other form’s field before the operator and the current
> form’s field after the operator like this: 'DEPTID' = $DeptID-New$
>
>
>
> I thought that this was either more efficient or provided more predictable
> results (or maybe both). Does anyone else follow this convention? I have
> run across several instances in some custom workflow where that is reversed
> and I see $DeptID-New$ = 'DEPTID' which just feels wrong to me. Below is
> more detail to clarify my examples.
>
>
>
> Form A: field DeptID-New
>
> Form B: field DEPTID
>
>
>
> There is a filter on form A that does a set fields which reads its value
> from form B. I believe the proper syntax if I want to match the department
> ID fields between the forms is this:
>
> 'DEPTID' = $DeptID-New$
>
>
>
> From there the set fields action can copy values from the matching record
> in form B into the fields of form A.
>
>
>
>
>
> Thanks,
>
> Rick
>
>
>
> *_*
>
>
> *Rick Westbrock *AppOps Engineer | IT Department
> 24 Hour Fitness USA, Inc.
>
>
>  _ARSlist: "Where the Answers Are" and have been for 20 years_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Set Field If syntax when matching on another form

[Peter Romain]

I've always used the 'x' = $y$ version and find it really hard to understand
it when I look at code written the other way around!

BMC seems to use this method most of the time.

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Tanner, Doug
Sent: 17 October 2014 15:37
To: arslist@ARSLIST.ORG
Subject: Re: Set Field If syntax when matching on another form

 

** 

Rick, I am not sure if there is any performance gain, but I always go to the
database first. Doug

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock
Sent: Friday, October 17, 2014 10:35 AM
To: arslist@ARSLIST.ORG  
Subject: Set Field If syntax when matching on another form

 

** 

Hi all-

 

I wanted to get feedback on something I remember learning way back in a
Remedy class (pre-BMC) in Pleasanton to make sure that I am remembering
correctly. I seem to recall that I was told that the best practice when
writing the qualification for a Set Fields action from another form that you
should use the other form's field before the operator and the current form's
field after the operator like this: 'DEPTID' = $DeptID-New$

 

I thought that this was either more efficient or provided more predictable
results (or maybe both). Does anyone else follow this convention? I have run
across several instances in some custom workflow where that is reversed and
I see $DeptID-New$ = 'DEPTID' which just feels wrong to me. Below is more
detail to clarify my examples.

 

Form A: field DeptID-New

Form B: field DEPTID

 

There is a filter on form A that does a set fields which reads its value
from form B. I believe the proper syntax if I want to match the department
ID fields between the forms is this:

'DEPTID' = $DeptID-New$

 

>From there the set fields action can copy values from the matching record in
form B into the fields of form A.

 

 

Thanks,

Rick

 

_

Rick Westbrock
AppOps Engineer | IT Department
24 Hour Fitness USA, Inc.

 

_ARSlist: "Where the Answers Are" and have been for 20 years_ 

This email is subject to certain disclaimers, which may be reviewed via the
following link. http://compass-usa.com/Pages/Disclaimer.aspx. 

_ARSlist: "Where the Answers Are" and have been for 20 years_ 


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Set Field If syntax when matching on another form

[Rick Cook]

I'm pretty sure that the query optimizers make the actual listed syntax
irrelevant, but I like to be consistent for appearances sake.  It's really
a matter of preference.

Rick Cook

On Fri, Oct 17, 2014 at 8:20 AM, Peter Romain <
p.romain.arsl...@parsolutions.co.uk> wrote:

> **
>
> I’ve always used the ‘x’ = $y$ version and find it really hard to
> understand it when I look at code written the other way around!
>
> BMC seems to use this method most of the time.
>
>
>
> *From:* Action Request System discussion list(ARSList) [mailto:
> arslist@ARSLIST.ORG] *On Behalf Of *Tanner, Doug
> *Sent:* 17 October 2014 15:37
> *To:* arslist@ARSLIST.ORG
> *Subject:* Re: Set Field If syntax when matching on another form
>
>
>
> **
>
> Rick, I am not sure if there is any performance gain, but I always go to
> the database first. Doug
>
>
>
> *From:* Action Request System discussion list(ARSList) [
> mailto:arslist@ARSLIST.ORG ] *On Behalf Of *Rick
> Westbrock
> *Sent:* Friday, October 17, 2014 10:35 AM
> *To:* arslist@ARSLIST.ORG
> *Subject:* Set Field If syntax when matching on another form
>
>
>
> **
>
> Hi all-
>
>
>
> I wanted to get feedback on something I remember learning way back in a
> Remedy class (pre-BMC) in Pleasanton to make sure that I am remembering
> correctly. I seem to recall that I was told that the best practice when
> writing the qualification for a Set Fields action from another form that
> you should use the other form’s field before the operator and the current
> form’s field after the operator like this: 'DEPTID' = $DeptID-New$
>
>
>
> I thought that this was either more efficient or provided more predictable
> results (or maybe both). Does anyone else follow this convention? I have
> run across several instances in some custom workflow where that is reversed
> and I see $DeptID-New$ = 'DEPTID' which just feels wrong to me. Below is
> more detail to clarify my examples.
>
>
>
> Form A: field DeptID-New
>
> Form B: field DEPTID
>
>
>
> There is a filter on form A that does a set fields which reads its value
> from form B. I believe the proper syntax if I want to match the department
> ID fields between the forms is this:
>
> 'DEPTID' = $DeptID-New$
>
>
>
> From there the set fields action can copy values from the matching record
> in form B into the fields of form A.
>
>
>
>
>
> Thanks,
>
> Rick
>
>
>
> *_*
>
>
> *Rick Westbrock*AppOps Engineer | IT Department
> 24 Hour Fitness USA, Inc.
>
>
>
> _ARSlist: "Where the Answers Are" and have been for 20 years_
>
> This email is subject to certain disclaimers, which may be reviewed via
> the following link. http://compass-usa.com/Pages/Disclaimer.aspx.
>
> _ARSlist: "Where the Answers Are" and have been for 20 years_
> _ARSlist: "Where the Answers Are" and have been for 20 years_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Set Field If syntax when matching on another form

[Thad Esser]

Same here, 'Field' = $Value$ is what I use, but I'm not really sure why.
As Sonny from "I, Robot" (the movie) says, "It just feels wrong."  :-)

If the $Value$ were null, does that mess with things at all?  You'd
essentially be saying: where null = 'Field' .  I'd assume that was handled
or there'd be more issues.  Just a thought.

Thad


On Fri, Oct 17, 2014 at 8:11 AM, LJ LongWing  wrote:

> **
> Rick,
> This is one of my personal pet peeves.  I started learning database and
> Remedy around the same time, and all of the instruction that I ever
> received in the database, and what makes most sense to me is
>
> field = value
>
> This translates in a remedy world to
>
> 'Field' = $Value$
>
> So, from this convention, I always use it as you state you prefer.  Over
> the years, I have found TONS of different contractors that come and go use
>
> $Value$ = 'Field'
>
> and while I don't believe it causes any performance impact in any way to
> do it that way, it's visually unappealing to me...it took me awhile, but I
> eventually figured out WHY some developers produce code that looks like
> that.  It has to do how things show up in the drop down in the Dev Studio.
> When building a setfield action, or push for that matter I think, when
> selecting fields, 'Current Form' is always the 'default', and current form
> is the one that produces $Value$, where 'form that it's being selected
> from' is not the defaultso, what you get is the developer selecting the
> field on the current form first, and the 'other' form second, which builds a
>
> $Value$ = 'Field'
>
> type of qualificationso, while I don't think it causes any problems,
> it's certainly not visually appealing to me...and I agree with you that it
> 'should be' the other way.
>
> On Fri, Oct 17, 2014 at 8:34 AM, Rick Westbrock 
> wrote:
>
>> **
>>
>> Hi all-
>>
>>
>>
>> I wanted to get feedback on something I remember learning way back in a
>> Remedy class (pre-BMC) in Pleasanton to make sure that I am remembering
>> correctly. I seem to recall that I was told that the best practice when
>> writing the qualification for a Set Fields action from another form that
>> you should use the other form’s field before the operator and the current
>> form’s field after the operator like this: 'DEPTID' = $DeptID-New$
>>
>>
>>
>> I thought that this was either more efficient or provided more
>> predictable results (or maybe both). Does anyone else follow this
>> convention? I have run across several instances in some custom workflow
>> where that is reversed and I see $DeptID-New$ = 'DEPTID' which just feels
>> wrong to me. Below is more detail to clarify my examples.
>>
>>
>>
>> Form A: field DeptID-New
>>
>> Form B: field DEPTID
>>
>>
>>
>> There is a filter on form A that does a set fields which reads its value
>> from form B. I believe the proper syntax if I want to match the department
>> ID fields between the forms is this:
>>
>> 'DEPTID' = $DeptID-New$
>>
>>
>>
>> From there the set fields action can copy values from the matching record
>> in form B into the fields of form A.
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Rick
>>
>>
>>
>> *_*
>>
>>
>> *Rick Westbrock *AppOps Engineer | IT Department
>> 24 Hour Fitness USA, Inc.
>>
>>
>>  _ARSlist: "Where the Answers Are" and have been for 20 years_
>
>
> _ARSlist: "Where the Answers Are" and have been for 20 years_
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

ARInside not showing DB or TR field prefixes

[Rick Westbrock]

I love the new interface in 3.1.1, great usability improvements John. One thing 
that I noticed which I think has been there all along is that if a filter 
qualification used the TR or DB prefix on a field name that is not represented 
in the documentation.

ARInside shows: 'EMPL_STATUS_yang' != 'EMPL_STATUS_yang'
Filter qualification: 'EMPL_STATUS' != 'DB.EMPL_STATUS'

I was investigating some custom workflow and when I saw that qualification on 
the ARInside page I was puzzled as to why someone would use that in a 
qualification (or even how that could ever be true for that matter). When I 
opened the filter it was using the DB prefix as shown above. Is this a known 
issue that I missed?

-Rick


From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Luthgers, John
Sent: Monday, September 01, 2014 7:14 AM
To: arslist@ARSLIST.ORG
Subject: ARInside 3.1.1 released

**
Hello List,

today I’m announcing the release of ARInside 3.1.1. The 3.1.x version focuses 
on redesign of the documentation layout and more dynamic functionality. 
Currently only the schema page is redesigned but everything else will follow 
and will receive further improvements. And it has updated support for ARS 
version 8.1.

You could find the download and the changes of this version at the ARInside 
website (http://arinside.org).

-John-

_ARSlist: "Where the Answers Are" and have been for 20 years_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Set Field If syntax when matching on another form

[Carl Wilson]

Hi,

Depending on the Database used, referencing the local field first (and not the 
remote table field) will cause the Database to skip the use of the indexes on 
the remote table and thus cause performance issues with the query.

This was mainly present in MS SQL as opposed to Oracle from memory.  

 

  _  

 

Kind Regards,

 

Carl Wilson

 

 

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Thad Esser
Sent: 17 October 2014 16:34
To: arslist@ARSLIST.ORG
Subject: Re: Set Field If syntax when matching on another form

 

** 

 

Same here, 'Field' = $Value$ is what I use, but I'm not really sure why.  As 
Sonny from "I, Robot" (the movie) says, "It just feels wrong."  :-)

 

If the $Value$ were null, does that mess with things at all?  You'd essentially 
be saying: where null = 'Field' .  I'd assume that was handled or there'd be 
more issues.  Just a thought.

 

Thad

 

 

On Fri, Oct 17, 2014 at 8:11 AM, LJ LongWing  wrote:

** 

Rick,

This is one of my personal pet peeves.  I started learning database and Remedy 
around the same time, and all of the instruction that I ever received in the 
database, and what makes most sense to me is

 

field = value

 

This translates in a remedy world to

 

'Field' = $Value$

 

So, from this convention, I always use it as you state you prefer.  Over the 
years, I have found TONS of different contractors that come and go use

 

$Value$ = 'Field'

 

and while I don't believe it causes any performance impact in any way to do it 
that way, it's visually unappealing to me...it took me awhile, but I eventually 
figured out WHY some developers produce code that looks like that.  It has to 
do how things show up in the drop down in the Dev Studio.  When building a 
setfield action, or push for that matter I think, when selecting fields, 
'Current Form' is always the 'default', and current form is the one that 
produces $Value$, where 'form that it's being selected from' is not the 
defaultso, what you get is the developer selecting the field on the current 
form first, and the 'other' form second, which builds a

 

$Value$ = 'Field'

 

type of qualificationso, while I don't think it causes any problems, it's 
certainly not visually appealing to me...and I agree with you that it 'should 
be' the other way.

 

On Fri, Oct 17, 2014 at 8:34 AM, Rick Westbrock  
wrote:

** 

Hi all-

 

I wanted to get feedback on something I remember learning way back in a Remedy 
class (pre-BMC) in Pleasanton to make sure that I am remembering correctly. I 
seem to recall that I was told that the best practice when writing the 
qualification for a Set Fields action from another form that you should use the 
other form’s field before the operator and the current form’s field after the 
operator like this: 'DEPTID' = $DeptID-New$

 

I thought that this was either more efficient or provided more predictable 
results (or maybe both). Does anyone else follow this convention? I have run 
across several instances in some custom workflow where that is reversed and I 
see $DeptID-New$ = 'DEPTID' which just feels wrong to me. Below is more detail 
to clarify my examples.

 

Form A: field DeptID-New

Form B: field DEPTID

 

There is a filter on form A that does a set fields which reads its value from 
form B. I believe the proper syntax if I want to match the department ID fields 
between the forms is this:

'DEPTID' = $DeptID-New$

 

>From there the set fields action can copy values from the matching record in 
>form B into the fields of form A.

 

 

Thanks,

Rick

 

_

Rick Westbrock
AppOps Engineer | IT Department
24 Hour Fitness USA, Inc.

 

_ARSlist: "Where the Answers Are" and have been for 20 years_ 

 

_ARSlist: "Where the Answers Are" and have been for 20 years_ 

 

_ARSlist: "Where the Answers Are" and have been for 20 years_ 


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Stuck at Executing SQLs in 8.1 Stack Installer

[Aedrian Escultura]

Hi Vivek,

 

Thanks for your response.

 

 

I have checked with our DBAs and have confirmed that the parameters have
been set as per BMC recommendation.

Tried setting use_zero_copy_io=false but it did not solve the problem as
well.

 

I tried going into silent install mode and got this error:

 

(Oct 17 2014 10:48:02.271 AM
-0500),SEVERE,com.bmc.install.product.bsm.arsuitekit.tasks.ARServerOracl
eManageDatabaseTask,

  LOG EVENT {Description=[Error while exporting the
tablespace],Detail=[Failed to import the tablespace[Exception running
command: Cannot run program "\bin\imp" (in directory
"C:\Users\myuser\AppData\Local\Temp\Utilities\rik"): CreateProcess
error=3, The system cannot find the path specified

]]}

 

I have set ORACLE_HOME to D:\Oracle\product\11.2.0\client_1\bin (also
tried D:\Oracle\product\11.2.0\client_1) but both didn't work.  PATH
also contains the path to the oracle client's bin directory as well so
not sure why it's not able see imp.exe in there.

 

Regards,

Aedrian

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Patil, Vivek
Sent: Thursday, October 16, 2014 11:34 PM
To: arslist@ARSLIST.ORG
Subject: Re: Stuck at Executing SQLs in 8.1 Stack Installer

 

** 

Hi Aedrian,

   Can you please refer
https://docs.bmc.com/docs/display/public/itsm81/Configuring+Oracle+datab
ases 

And
https://docs.bmc.com/docs/display/public/itsm81/Installing+the+BMC+Remed
y+ITSM+Suite+Preconfigured+Stack

 

In your case we would recommend you to review Oracle Configuration as
provided by BMC. Let us know the results.

 

NOTE : 

#For 8.1 ITSM and Oracle 11g we observed installer hanging once. #ORACLE
Bug ID is: 13017584

The workaround for hang issue is to make use of Special Oracle
parameters for "_use_zero_copy_io=false".

Define this parameter in init.ora file for the instance and restart DB.
(You can find this file under \database directory. Generally
this file is named as "init.ora".)

 

 

Thanks,
  Vivek

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Aedrian Escultura
Sent: Thursday, October 16, 2014 8:25 PM
To: arslist@ARSLIST.ORG
Subject: Stuck at Executing SQLs in 8.1 Stack Installer

 

** 

Hi ARSList,

 

Has anyone ever encountered an issue running the 8.1 stack installer -
particularly at the Execute SQLs part? (Screenshot attached)

 

I can see that it was able to create only the ACTLINK table, nothing
after that.  DB sessions are all inactive.

Even the C:\Users\myuser\AppData\Local\Temp\ARSystemDBImport.log does
not contain anything.  

 

Appreciate any help you can provide.

 

Windows Server 2008

Oracle 11g R2

 

Thanks,

Aedrian

 

This email, including any attachments, is confidential. If you are not
the intended recipient, you must not disclose, distribute or use the
information in this email in any way. If you received this email in
error, please notify the sender immediately by return email and delete
the message. Unless expressly stated otherwise, the information in this
email should not be regarded as an offer to sell or as a solicitation of
an offer to buy any financial product or service, an official
confirmation of any transaction, or as an official statement of the
entity sending this message. Neither Macquarie Group Limited, nor any of
its subsidiaries, guarantee the integrity of any emails or attached
files and are not responsible for any changes made to them by any other
person.

 

_ARSlist: "Where the Answers Are" and have been for 20 years_ 

_ARSlist: "Where the Answers Are" and have been for 20 years_ 


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Set Field If syntax when matching on another form

[Rick Westbrock]

Thanks for all the feedback. I was on MSSQL back when I learned this but am on 
Oracle now so I won’t spend the time to change these when I run across them for 
now. If I have time I might ping BMC Support to see if they have a definitive 
answer.

Carl I like that you reference local and remote forms, that’s how I normally 
refer to them myself but I was afraid that some people might think I meant a 
form on another server.

-Rick

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Carl Wilson
Sent: Friday, October 17, 2014 9:04 AM
To: arslist@ARSLIST.ORG
Subject: Re: Set Field If syntax when matching on another form

**
Hi,
Depending on the Database used, referencing the local field first (and not the 
remote table field) will cause the Database to skip the use of the indexes on 
the remote table and thus cause performance issues with the query.
This was mainly present in MS SQL as opposed to Oracle from memory.



Kind Regards,

Carl Wilson


From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Thad Esser
Sent: 17 October 2014 16:34
To: arslist@ARSLIST.ORG
Subject: Re: Set Field If syntax when matching on another form

**

Same here, 'Field' = $Value$ is what I use, but I'm not really sure why.  As 
Sonny from "I, Robot" (the movie) says, "It just feels wrong."  :-)

If the $Value$ were null, does that mess with things at all?  You'd essentially 
be saying: where null = 'Field' .  I'd assume that was handled or there'd be 
more issues.  Just a thought.

Thad


On Fri, Oct 17, 2014 at 8:11 AM, LJ LongWing 
mailto:lj.longw...@gmail.com>> wrote:
**
Rick,
This is one of my personal pet peeves.  I started learning database and Remedy 
around the same time, and all of the instruction that I ever received in the 
database, and what makes most sense to me is

field = value

This translates in a remedy world to

'Field' = $Value$

So, from this convention, I always use it as you state you prefer.  Over the 
years, I have found TONS of different contractors that come and go use

$Value$ = 'Field'

and while I don't believe it causes any performance impact in any way to do it 
that way, it's visually unappealing to me...it took me awhile, but I eventually 
figured out WHY some developers produce code that looks like that.  It has to 
do how things show up in the drop down in the Dev Studio.  When building a 
setfield action, or push for that matter I think, when selecting fields, 
'Current Form' is always the 'default', and current form is the one that 
produces $Value$, where 'form that it's being selected from' is not the 
defaultso, what you get is the developer selecting the field on the current 
form first, and the 'other' form second, which builds a

$Value$ = 'Field'

type of qualificationso, while I don't think it causes any problems, it's 
certainly not visually appealing to me...and I agree with you that it 'should 
be' the other way.

On Fri, Oct 17, 2014 at 8:34 AM, Rick Westbrock 
mailto:rwestbr...@24hourfit.com>> wrote:
**
Hi all-

I wanted to get feedback on something I remember learning way back in a Remedy 
class (pre-BMC) in Pleasanton to make sure that I am remembering correctly. I 
seem to recall that I was told that the best practice when writing the 
qualification for a Set Fields action from another form that you should use the 
other form’s field before the operator and the current form’s field after the 
operator like this: 'DEPTID' = $DeptID-New$

I thought that this was either more efficient or provided more predictable 
results (or maybe both). Does anyone else follow this convention? I have run 
across several instances in some custom workflow where that is reversed and I 
see $DeptID-New$ = 'DEPTID' which just feels wrong to me. Below is more detail 
to clarify my examples.

Form A: field DeptID-New
Form B: field DEPTID

There is a filter on form A that does a set fields which reads its value from 
form B. I believe the proper syntax if I want to match the department ID fields 
between the forms is this:
'DEPTID' = $DeptID-New$

From there the set fields action can copy values from the matching record in 
form B into the fields of form A.


Thanks,
Rick

_
Rick Westbrock
AppOps Engineer | IT Department
24 Hour Fitness USA, Inc.

_ARSlist: "Where the Answers Are" and have been for 20 years_

_ARSlist: "Where the Answers Are" and have been for 20 years_

_ARSlist: "Where the Answers Are" and have been for 20 years_
_ARSlist: "Where the Answers Are" and have been for 20 years_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: ARInside not showing DB or TR field prefixes

[Thad Esser]

Hi Rick,

There's a newer version 3.1.2 where he fixed that bug.

Thad

On Fri, Oct 17, 2014 at 8:51 AM, Rick Westbrock 
wrote:

> **
>
> I love the new interface in 3.1.1, great usability improvements John. One
> thing that I noticed which I think has been there all along is that if a
> filter qualification used the TR or DB prefix on a field name that is not
> represented in the documentation.
>
>
>
> *ARInside shows:* 'EMPL_STATUS_yang' != 'EMPL_STATUS_yang'
>
> *Filter qualification:* 'EMPL_STATUS' != 'DB.EMPL_STATUS'
>
>
>
> I was investigating some custom workflow and when I saw that qualification
> on the ARInside page I was puzzled as to why someone would use that in a
> qualification (or even how that could ever be true for that matter). When I
> opened the filter it was using the DB prefix as shown above. Is this a
> known issue that I missed?
>
>
>
> -Rick
>
>
>
>
>
> *From:* Action Request System discussion list(ARSList) [mailto:
> arslist@ARSLIST.ORG] *On Behalf Of *Luthgers, John
> *Sent:* Monday, September 01, 2014 7:14 AM
> *To:* arslist@ARSLIST.ORG
> *Subject:* ARInside 3.1.1 released
>
>
>
> **
>
> Hello List,
>
>
>
> today I’m announcing the release of ARInside 3.1.1. The 3.1.x version
> focuses on redesign of the documentation layout and more dynamic
> functionality. Currently only the schema page is redesigned but everything
> else will follow and will receive further improvements. And it has updated
> support for ARS version 8.1.
>
>
>
> You could find the download and the changes of this version at the
> ARInside website (http://arinside.org).
>
>
>
> -John-
>
>
>
> _ARSlist: "Where the Answers Are" and have been for 20 years_
>  _ARSlist: "Where the Answers Are" and have been for 20 years_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: ARInside not showing DB or TR field prefixes

[Rick Westbrock]

Thanks Thad, I hadn’t gotten around to installing the latest update yet. I must 
not have read the release notes on that one.

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Thad Esser
Sent: Friday, October 17, 2014 9:29 AM
To: arslist@ARSLIST.ORG
Subject: Re: ARInside not showing DB or TR field prefixes

**
Hi Rick,

There's a newer version 3.1.2 where he fixed that bug.

Thad

On Fri, Oct 17, 2014 at 8:51 AM, Rick Westbrock 
mailto:rwestbr...@24hourfit.com>> wrote:
**
I love the new interface in 3.1.1, great usability improvements John. One thing 
that I noticed which I think has been there all along is that if a filter 
qualification used the TR or DB prefix on a field name that is not represented 
in the documentation.

ARInside shows: 'EMPL_STATUS_yang' != 'EMPL_STATUS_yang'
Filter qualification: 'EMPL_STATUS' != 'DB.EMPL_STATUS'

I was investigating some custom workflow and when I saw that qualification on 
the ARInside page I was puzzled as to why someone would use that in a 
qualification (or even how that could ever be true for that matter). When I 
opened the filter it was using the DB prefix as shown above. Is this a known 
issue that I missed?

-Rick


From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Luthgers, 
John
Sent: Monday, September 01, 2014 7:14 AM
To: arslist@ARSLIST.ORG
Subject: ARInside 3.1.1 released

**
Hello List,

today I’m announcing the release of ARInside 3.1.1. The 3.1.x version focuses 
on redesign of the documentation layout and more dynamic functionality. 
Currently only the schema page is redesigned but everything else will follow 
and will receive further improvements. And it has updated support for ARS 
version 8.1.

You could find the download and the changes of this version at the ARInside 
website (http://arinside.org).

-John-

_ARSlist: "Where the Answers Are" and have been for 20 years_
_ARSlist: "Where the Answers Are" and have been for 20 years_

_ARSlist: "Where the Answers Are" and have been for 20 years_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: ENGAGE 2014 Commentary

[Rick Westbrock]

Wow, you subjected yourselves to that travesty of a "ride"? Did you lose a bet? 
Your brains will be addled for days...

Thanks for all the great commentary this week Doug, it was very interesting 
reading for those like myself who couldn't make it out this year.

-Rick

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Doug Blair
Sent: Friday, October 17, 2014 10:03 AM
To: arslist@ARSLIST.ORG
Subject: Re: ENGAGE 2014 Commentary

>From Disney World, Magic Kingdom. Three Remedy Developers, separated by a 
>common language. It's a small world :-)


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers 
Are, and have been for 20 years"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

ARUtilities 6.3

[Drake, David]

Anyone know where you can still get a copy of the ARUtilities 6.3 software?


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Set Field If syntax when matching on another form

[Lucero, Michelle]

Hi, Everyone:

I thought I was the only one who feels automatically driven, like some outside 
force will punish me if I don’t stick to the ‘Field’ = $Value$ syntax.  I can’t 
write it any other way.  I just can’t.  Let me try, $Valu….  Nope, can’t do it. 
 It is literally a physical reaction in my gut that won’t let me.

With that said, I’m with Carl and Rick.

I do believe that in the AR System Performance, Tuning and Troubleshooting 3.x  
class that we learned to start with remote form.field first and current.value 
second in qualifications.  On page 238 of the manual  (copyright 1997 Remedy 
Corporation), although Set fields aren’t referenced specifically, samples to 
promote index use are written ‘Field’ = “known value” or ‘Field’ >= value.

My two cents,
Michelle

P.S.
To Whomever taught this class in Dallas (Richardson), TX in August 1997 – Thank 
you.  This is by far the best Remedy class, I’ve ever attended.  I still use 
the Performance Tuning tips to this day.  I still offset escalation interval 
times to make sure they’re not a factor of 60.   I still use >= to give an 
index a starting point, etc.

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock
Sent: Friday, October 17, 2014 11:11 AM
To: arslist@ARSLIST.ORG
Subject: Re: Set Field If syntax when matching on another form

**
Thanks for all the feedback. I was on MSSQL back when I learned this but am on 
Oracle now so I won’t spend the time to change these when I run across them for 
now. If I have time I might ping BMC Support to see if they have a definitive 
answer.

Carl I like that you reference local and remote forms, that’s how I normally 
refer to them myself but I was afraid that some people might think I meant a 
form on another server.

-Rick

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Carl Wilson
Sent: Friday, October 17, 2014 9:04 AM
To: arslist@ARSLIST.ORG
Subject: Re: Set Field If syntax when matching on another form

**
Hi,
Depending on the Database used, referencing the local field first (and not the 
remote table field) will cause the Database to skip the use of the indexes on 
the remote table and thus cause performance issues with the query.
This was mainly present in MS SQL as opposed to Oracle from memory.



Kind Regards,

Carl Wilson


From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Thad Esser
Sent: 17 October 2014 16:34
To: arslist@ARSLIST.ORG
Subject: Re: Set Field If syntax when matching on another form

**

Same here, 'Field' = $Value$ is what I use, but I'm not really sure why.  As 
Sonny from "I, Robot" (the movie) says, "It just feels wrong."  :-)

If the $Value$ were null, does that mess with things at all?  You'd essentially 
be saying: where null = 'Field' .  I'd assume that was handled or there'd be 
more issues.  Just a thought.

Thad


On Fri, Oct 17, 2014 at 8:11 AM, LJ LongWing 
mailto:lj.longw...@gmail.com>> wrote:
**
Rick,
This is one of my personal pet peeves.  I started learning database and Remedy 
around the same time, and all of the instruction that I ever received in the 
database, and what makes most sense to me is

field = value

This translates in a remedy world to

'Field' = $Value$

So, from this convention, I always use it as you state you prefer.  Over the 
years, I have found TONS of different contractors that come and go use

$Value$ = 'Field'

and while I don't believe it causes any performance impact in any way to do it 
that way, it's visually unappealing to me...it took me awhile, but I eventually 
figured out WHY some developers produce code that looks like that.  It has to 
do how things show up in the drop down in the Dev Studio.  When building a 
setfield action, or push for that matter I think, when selecting fields, 
'Current Form' is always the 'default', and current form is the one that 
produces $Value$, where 'form that it's being selected from' is not the 
defaultso, what you get is the developer selecting the field on the current 
form first, and the 'other' form second, which builds a

$Value$ = 'Field'

type of qualificationso, while I don't think it causes any problems, it's 
certainly not visually appealing to me...and I agree with you that it 'should 
be' the other way.

On Fri, Oct 17, 2014 at 8:34 AM, Rick Westbrock 
mailto:rwestbr...@24hourfit.com>> wrote:
**
Hi all-

I wanted to get feedback on something I remember learning way back in a Remedy 
class (pre-BMC) in Pleasanton to make sure that I am remembering correctly. I 
seem to recall that I was told that the best practice when writing the 
qualification for a Set Fields action from another form that you should use the 
other form’s field before the operator and the current form’s field after the 
operator like this: 'DEPTID' = $DeptID-New$

I thought that t

Re: Set Field If syntax when matching on another form

[Rick Westbrock]

Whew, glad it wasn’t just me! I was taught by Sydney Dent probably about ten 
years ago IIRC. I learned a lot from that class that I have used over the 
years. It does grate on me every time I see the “backwards” syntax even if it 
doesn’t affect anything except my brain. Have a great weekend all!

-Rick

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Lucero, Michelle
Sent: Friday, October 17, 2014 3:09 PM
To: arslist@ARSLIST.ORG
Subject: Re: Set Field If syntax when matching on another form

**
Hi, Everyone:

I thought I was the only one who feels automatically driven, like some outside 
force will punish me if I don’t stick to the ‘Field’ = $Value$ syntax.  I can’t 
write it any other way.  I just can’t.  Let me try, $Valu….  Nope, can’t do it. 
 It is literally a physical reaction in my gut that won’t let me.

With that said, I’m with Carl and Rick.

I do believe that in the AR System Performance, Tuning and Troubleshooting 3.x  
class that we learned to start with remote form.field first and current.value 
second in qualifications.  On page 238 of the manual  (copyright 1997 Remedy 
Corporation), although Set fields aren’t referenced specifically, samples to 
promote index use are written ‘Field’ = “known value” or ‘Field’ >= value.

My two cents,
Michelle

P.S.
To Whomever taught this class in Dallas (Richardson), TX in August 1997 – Thank 
you.  This is by far the best Remedy class, I’ve ever attended.  I still use 
the Performance Tuning tips to this day.  I still offset escalation interval 
times to make sure they’re not a factor of 60.   I still use >= to give an 
index a starting point, etc.

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock
Sent: Friday, October 17, 2014 11:11 AM
To: arslist@ARSLIST.ORG
Subject: Re: Set Field If syntax when matching on another form

**
Thanks for all the feedback. I was on MSSQL back when I learned this but am on 
Oracle now so I won’t spend the time to change these when I run across them for 
now. If I have time I might ping BMC Support to see if they have a definitive 
answer.

Carl I like that you reference local and remote forms, that’s how I normally 
refer to them myself but I was afraid that some people might think I meant a 
form on another server.

-Rick

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Carl Wilson
Sent: Friday, October 17, 2014 9:04 AM
To: arslist@ARSLIST.ORG
Subject: Re: Set Field If syntax when matching on another form

**
Hi,
Depending on the Database used, referencing the local field first (and not the 
remote table field) will cause the Database to skip the use of the indexes on 
the remote table and thus cause performance issues with the query.
This was mainly present in MS SQL as opposed to Oracle from memory.



Kind Regards,

Carl Wilson


From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Thad Esser
Sent: 17 October 2014 16:34
To: arslist@ARSLIST.ORG
Subject: Re: Set Field If syntax when matching on another form

**

Same here, 'Field' = $Value$ is what I use, but I'm not really sure why.  As 
Sonny from "I, Robot" (the movie) says, "It just feels wrong."  :-)

If the $Value$ were null, does that mess with things at all?  You'd essentially 
be saying: where null = 'Field' .  I'd assume that was handled or there'd be 
more issues.  Just a thought.

Thad


On Fri, Oct 17, 2014 at 8:11 AM, LJ LongWing 
mailto:lj.longw...@gmail.com>> wrote:
**
Rick,
This is one of my personal pet peeves.  I started learning database and Remedy 
around the same time, and all of the instruction that I ever received in the 
database, and what makes most sense to me is

field = value

This translates in a remedy world to

'Field' = $Value$

So, from this convention, I always use it as you state you prefer.  Over the 
years, I have found TONS of different contractors that come and go use

$Value$ = 'Field'

and while I don't believe it causes any performance impact in any way to do it 
that way, it's visually unappealing to me...it took me awhile, but I eventually 
figured out WHY some developers produce code that looks like that.  It has to 
do how things show up in the drop down in the Dev Studio.  When building a 
setfield action, or push for that matter I think, when selecting fields, 
'Current Form' is always the 'default', and current form is the one that 
produces $Value$, where 'form that it's being selected from' is not the 
defaultso, what you get is the developer selecting the field on the current 
form first, and the 'other' form second, which builds a

$Value$ = 'Field'

type of qualificationso, while I don't think it causes any problems, it's 
certainly not visually appealing to me...and I agree with you that it 'shou

Re: Set Field If syntax when matching on another form

[Carl Wilson]

In addition to this, when I was with Column we did a lot of testing of these 
types of queries against different DB's for performance tuning - so although 
some people do say that it does not make a difference we did prove that the 
indexes were skipped in certain instances on different DB's.

When I made my logging application, I added a tab that showed where the 
qualifications are "backwards" in their logic due to the above.  Other third 
party logging tools also do the same where they indicate that the query 
"should" be reversed for optimal performance.

 

Always a good rule of thumb to stick to the rule of referencing the external 
(or non local/remote) table field first in the qualification, although this may 
be now mitigated in the latest versions of the DB's used [good coding practise] 
J

 

  _  

 

Kind Regards,

 

Carl Wilson

 

 

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock
Sent: 17 October 2014 23:17
To: arslist@ARSLIST.ORG
Subject: Re: Set Field If syntax when matching on another form

 

** 

Whew, glad it wasn’t just me! I was taught by Sydney Dent probably about ten 
years ago IIRC. I learned a lot from that class that I have used over the 
years. It does grate on me every time I see the “backwards” syntax even if it 
doesn’t affect anything except my brain. Have a great weekend all!

 

-Rick

 

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Lucero, Michelle
Sent: Friday, October 17, 2014 3:09 PM
To: arslist@ARSLIST.ORG
Subject: Re: Set Field If syntax when matching on another form

 

** 

Hi, Everyone:

 

I thought I was the only one who feels automatically driven, like some outside 
force will punish me if I don’t stick to the ‘Field’ = $Value$ syntax.  I can’t 
write it any other way.  I just can’t.  Let me try, $Valu….  Nope, can’t do it. 
 It is literally a physical reaction in my gut that won’t let me.

 

With that said, I’m with Carl and Rick. 

 

I do believe that in the AR System Performance, Tuning and Troubleshooting 3.x  
class that we learned to start with remote form.field first and current.value 
second in qualifications.  On page 238 of the manual  (copyright 1997 Remedy 
Corporation), although Set fields aren’t referenced specifically, samples to 
promote index use are written ‘Field’ = “known value” or ‘Field’ >= value.

 

My two cents,

Michelle

 

P.S.

To Whomever taught this class in Dallas (Richardson), TX in August 1997 – Thank 
you.  This is by far the best Remedy class, I’ve ever attended.  I still use 
the Performance Tuning tips to this day.  I still offset escalation interval 
times to make sure they’re not a factor of 60.   I still use >= to give an 
index a starting point, etc. 

 

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock
Sent: Friday, October 17, 2014 11:11 AM
To: arslist@ARSLIST.ORG
Subject: Re: Set Field If syntax when matching on another form

 

** 

Thanks for all the feedback. I was on MSSQL back when I learned this but am on 
Oracle now so I won’t spend the time to change these when I run across them for 
now. If I have time I might ping BMC Support to see if they have a definitive 
answer.

 

Carl I like that you reference local and remote forms, that’s how I normally 
refer to them myself but I was afraid that some people might think I meant a 
form on another server.

 

-Rick

 

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Carl Wilson
Sent: Friday, October 17, 2014 9:04 AM
To: arslist@ARSLIST.ORG
Subject: Re: Set Field If syntax when matching on another form

 

** 

Hi,

Depending on the Database used, referencing the local field first (and not the 
remote table field) will cause the Database to skip the use of the indexes on 
the remote table and thus cause performance issues with the query.

This was mainly present in MS SQL as opposed to Oracle from memory.  

 

  _  

 

Kind Regards,

 

Carl Wilson

 

 

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Thad Esser
Sent: 17 October 2014 16:34
To: arslist@ARSLIST.ORG
Subject: Re: Set Field If syntax when matching on another form

 

** 

 

Same here, 'Field' = $Value$ is what I use, but I'm not really sure why.  As 
Sonny from "I, Robot" (the movie) says, "It just feels wrong."  :-)

 

If the $Value$ were null, does that mess with things at all?  You'd essentially 
be saying: where null = 'Field' .  I'd assume that was handled or there'd be 
more issues.  Just a thought.

 

Thad

 

 

On Fri, Oct 17, 2014 at 8:11 AM, LJ LongWing  wrote:

** 

Rick,

This is one of my personal pet peeves.  I started learning database and Remedy 
around the same time, and all of the instruction that I ever received in the 
database, and what makes most sense to me is

 

field = value

 

This translat

Re: ARUtilities 6.3

[Carl Wilson]

Is there a specific reason you need that version i.e. Licence?

I have a copy if required, ping me privately and I can supply a copy.

 

  _  

 

Kind Regards,

 

Carl Wilson

 

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Drake, David
Sent: 17 October 2014 22:32
To: arslist@ARSLIST.ORG
Subject: ARUtilities 6.3

 

** 

Anyone know where you can still get a copy of the ARUtilities 6.3 software?

 

_ARSlist: "Where the Answers Are" and have been for 20 years_ 


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: Open question to BMC on troubleshooting without the WUT

[Larry Robinson]

Hi John,

As it turns out, I no longer have access to the author of the program I
posted. Could elaborate on what the vulnerability is and how to implement
the same functionality in a more secure manner?

Thanks for your insights.
Larry

On Fri, Oct 17, 2014 at 1:26 AM, John Baker 
wrote:

> Larry
>
> I wouldn't suggest using that JSP :) It is running a native application
> (hostname) to get the hostname that is readily available from a Java API
> call.
>
> Running native applications isn't going to do the performance of your Mid
> Tier any good, and anyone with a copy of wget can almost certainly kill
> your Mid Tier pretty quickly.
>
> The Java InetAddress API is what you should be using for this task.
>
>
> John
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"