Hi, Susan:

Have you tried debugging the action as recommended in technote #1212?
It shd prove helpful in tracing the source of your problems.

Included below is the meat of the technote.

Hope this helps...

Wade H.W. Chia
CGI Telecommunications Information Systems and Services Inc.
595 Bay Street, #1100
Toronto (Ontario) M5G 2C2
mailto:wade.chia@bellsygma.com

-----------------------------------------

The following can be used as a guideline to help in debugging a filter
RunProcess action that is not executing
correctly.

Steps:

1. Put the AR System into Debug Trace Mode for the action you want to debug.

a. In the Admin Tool select File->Server Info, Category = Log Files.

b. Select and Apply the appropriate Debug Trace Mode.

2. Perform the action necessary to execute the RunProcess action.

3. Extract the command line that is logged in the Trace file. This is the exact
command that will be tested in next
step.

4. Execute the command from the Unix command line.

a. Login into the Unix system as the user that owns the arserverd process
(usually the root user). This is
necessary because escalations and filters are executed by the arserverd process
and thus have the same
environment and permissions.

b. RunProcess actions are executed under the Bourne shell. Be sure you are
running under a Bourne shell while
debugging.

c. Execute the command and observe any problems with its execution. If the
RunProcess action is `aruser -e
', run the command with the -i option instead of -e. This will bring

up the user tool and allow you
to see any error messages that may occur.

Conclusion:

RunProcess actions always return an OK status. No errors are logged to the debug

trace log file. In order to
debug a RunProcess action it is necessary to see any errors that may be occur
ring. The idea is to duplicate the
environment that the server has when executing the RunProc ess action and
observe errors that occur when
manually executing the action from the command line.

On Tue, 12 Jan 1999, Binette-Blair, Susan wrote:

Any chance that one of the fields is NULL? I see this quite often and you
get an expanded command line that looks like -p field1 -p -p field3 this
confuses the heck out of aruser and nothing will happen.


> Hi . . .
>
> Sorry if this has been covered before!
>
> I am attempting to merge one ticket (a) to another existing ticket (b)
> within the same schema. Diary fields are included. I have recorded a macro
> which performs a modify all on ticket (b). My macro is run from a run
> process within a filter triggered by a specific user action on ticket (a).
> According to the filter log and SQL log, everything looks just nifty.
> However, ticket (b) is not getting updated in any way.
>
> My run process command is as follows:
>
> aruser -d /opt/apps/ar/arcmds -e "CR Merge" -p "Master Match"=$Master CR #$
> -p "Comment Log" = $Comment Log$ -p "Description" = $Description$ -p
> "Justification" = $Justification$
> -p "Master" = $Master CR #$ -p "Last Merged" = $CR #$
>
> My "Master Match" finds ticket (b) based on entry-ID (so I know there will
> only be one match). All the other parameters should get copied from ticket
> (a).
>
> As the administrator, I have access to all fields on the schema. I know
> that filters run with admin permissions, but does the user tool get started
> with a specific logon/password? If so, which one?
>
> Help!
>
> ARS 3.0.1
> Solaris 2.5
> Oracle 7.1.3
> Clients: winnt 4.0
>
> Susan Binette-Blair
> INVESCO-Denver
>

--
Regards

David C. Saville | Second star to the right and
| straight on 'til morning.
Tel: +44 1293 55 6326 |
Fax: +44 1293 55 6470 | Capt. James T. Kirk (Quoting Peter Pan)

Hi, Susan:

Have you tried debugging the action as recommended
in technote #1212?
It shd prove helpful in tracing the source of your
problems.

Included below is the meat of the technote.

Hope this helps...

Wade H.W. Chia
CGI Telecommunications Information Systems and
Services Inc.
595 Bay Street, #1100
Toronto (Ontario) M5G 2C2
mailto:wade.chia@bellsygma.com

-----------------------------------------

The following can be used as a guideline to help
in debugging a filter
RunProcess action that is not executing
correctly.

Steps:

1. Put the AR System into Debug Trace Mode for the
action you want to debug.

a. In the Admin Tool select File->Server Info,
Category = Log Files.

b. Select and Apply the appropriate Debug Trace
Mode.

2. Perform the action necessary to execute the
RunProcess action.

3. Extract the command line that is logged in the
Trace file. This is the exact
command that will be tested in next
step.

4. Execute the command from the Unix command line.

a. Login into the Unix system as the user that
owns the arserverd process
(usually the root user). This is
necessary because escalations and filters are
executed by the arserverd process
and thus have the same
environment and permissions.

b. RunProcess actions are executed under the
Bourne shell. Be sure you are
running under a Bourne shell while
debugging.

c. Execute the command and observe any problems
with its execution. If the
RunProcess action is `aruser -e
', run the command with the -i option
instead of -e. This will bring

up the user tool and allow you
to see any error messages that may occur.

Conclusion:

RunProcess actions always return an OK status. No
errors are logged to the debug

trace log file. In order to
debug a RunProcess action it is necessary to see
any errors that may be occur
ring. The idea is to duplicate the
environment that the server has when executing the
RunProc ess action and
observe errors that occur when
manually executing the action from the command
line.

Hi, Susan:

Have you tried debugging the action as recommended
in technote #1212?
It shd prove helpful in tracing the source of your
problems.

Included below is the meat of the technote.

Hope this helps...

Wade H.W. Chia
CGI Telecommunications Information Systems and
Services Inc.
595 Bay Street, #1100
Toronto (Ontario) M5G 2C2
mailto:wade.chia@bellsygma.com

-----------------------------------------

The following can be used as a guideline to help
in debugging a filter
RunProcess action that is not executing
correctly.

Steps:

1. Put the AR System into Debug Trace Mode for the
action you want to debug.

a. In the Admin Tool select File->Server Info,
Category = Log Files.

b. Select and Apply the appropriate Debug Trace
Mode.

2. Perform the action necessary to execute the
RunProcess action.

3. Extract the command line that is logged in the
Trace file. This is the exact
command that will be tested in next
step.

4. Execute the command from the Unix command line.

a. Login into the Unix system as the user that
owns the arserverd process
(usually the root user). This is
necessary because escalations and filters are
executed by the arserverd process
and thus have the same
environment and permissions.

b. RunProcess actions are executed under the
Bourne shell. Be sure you are
running under a Bourne shell while
debugging.

c. Execute the command and observe any problems
with its execution. If the
RunProcess action is `aruser -e
', run the command with the -i option
instead of -e. This will bring

up the user tool and allow you
to see any error messages that may occur.

Conclusion:

RunProcess actions always return an OK status. No
errors are logged to the debug

trace log file. In order to
debug a RunProcess action it is necessary to see
any errors that may be occur
ring. The idea is to duplicate the
environment that the server has when executing the
RunProc ess action and
observe errors that occur when
manually executing the action from the command
line.

exporting ARHOME is good practice so that the system knows where to find
arHome/config
It uses this info in order to perform the login.
Another problem common with this sort of thing is when the macro were
created outside a UNIX env and you have a UNIX server. In this case, I have
had all sorts of quirks which were neatly resolved when I redid the macro
using the UNIX client tool.
Also, once I had created a macro at home that I FTPed to my UNIX machine at
work. After the FTP it had capitalized the extension (.arq to .ARQ) giving
me an error when I ran my filter (it could find it).

Good luck!

Peter

________________________________________
Peter Vogopoulos
Conseiller, Administrateur ARS
LE GROUPE CGI (Gestion des Technologies)
Tel: (514) 383-1611 x2015
mailto:Peter.V@cgi.ca


> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@LISTSERV.ACSU.BUFFALO.EDU]On Behalf Of Binette-Blair,
> Susan
> Sent: January 12, 1999 4:02 PM
> To: ARSLIST@LISTSERV.ACSU.BUFFALO.EDU
> Subject: Re: Run Process - macro
>
>
> I have added the double quotes as Phil suggested, and NOTHING seemed to
> change.
>
> I am NOT exporting the ARHOME variable. Why should I have to if it is
> explicitly stated in the run process command? And if I have to, at what
> point would that be done - as another run process command?
>
> Lastly, I have also added the full path name of the "aruser" exe, just in
> case it didn't know where to go.
>
> Thanks -
>
> Susan Binette-Blair
> -----Original Message-----
> From: Cornett, Manotee J. [mailto:manotee.cornett@TELDTA.COM]
> Sent: Tuesday, January 12, 1999 1:55 PM
> To: ARSLIST@LISTSERV.ACSU.BUFFALO.EDU
> Subject: Re: Run Process - macro
>
>
> Also, are you exporting ARHOME?
>
> > ----------
> > From: Phil Murnane[SMTP:philip.murnane@SSDS.COM]
> > Sent: 1/12/1999 2:38 PM
> > To: ARSLIST@LISTSERV.ACSU.BUFFALO.EDU
> > Subject: Re: Run Process - macro
> >
> > Susan:
> >
> > Try putting double-quotes around the substituted fields. Eg,
> >
> > aruser -d /opt/apps/ar/arcmds -e "CR Merge" -p "Master
> Match"="$Master CR
> > #$"
> > -p "Comment Log" = "$Comment Log$" -p "Description" =
> "$Description$" -p
> > "Justification" = "$Justification$" -p "Master" = "$Master CR
> #$" -p "Last
> > Merged" = "$CR #$"
> >
> > You may also have to add workflow to make sure there are no single- or
> > double-quotes in any of the field values because unix may get
> confused if
> > it
> > sees something like
> >
> > ... -p "$Description$" -p "Can you say, "confusing?"" ...
> >
> > after expanding the field into its value.
> >
> > HTH,
> > --Phil
> >
> >
> > -----Original Message-----
> > From: Action Request System discussion list(ARSList)
> > [mailto:ARSLIST@listserv.acsu.buffalo.edu]On Behalf Of Binette-Blair,
> > Susan
> > Sent: Tuesday, January 12, 1999 19:57
> > To: ARSLIST@listserv.acsu.buffalo.edu
> > Subject: Run Process - macro
> >
> >
> > Hi . . .
> >
> > Sorry if this has been covered before!
> >
> > I am attempting to merge one ticket (a) to another existing ticket (b)
> > within the same schema. Diary fields are included. I have recorded a
> > macro
> > which performs a modify all on ticket (b). My macro is run from a run
> > process within a filter triggered by a specific user action on
> ticket (a).
> > According to the filter log and SQL log, everything looks just nifty.
> > However, ticket (b) is not getting updated in any way.
> >
> > My run process command is as follows:
> >
> > aruser -d /opt/apps/ar/arcmds -e "CR Merge" -p "Master Match"=$Master CR
> > #$
> > -p "Comment Log" = $Comment Log$ -p "Description" = $Description$ -p
> > "Justification" = $Justification$
> > -p "Master" = $Master CR #$ -p "Last Merged" = $CR #$
> >
> > My "Master Match" finds ticket (b) based on entry-ID (so I know
> there will
> > only be one match). All the other parameters should get copied from
> > ticket
> > (a).
> >
> > As the administrator, I have access to all fields on the schema. I know
> > that filters run with admin permissions, but does the user tool get
> > started
> > with a specific logon/password? If so, which one?
> >
> > Help!
> >
> > ARS 3.0.1
> > Solaris 2.5
> > Oracle 7.1.3
> > Clients: winnt 4.0
> >
> > Susan Binette-Blair
> > INVESCO-Denver
> >
>