Using colon-length-colon (:85:) to wrap the PARMS option value is usually
preferable to using double quotes around the entire PARMS option value
because then you would need to escape the double quotes within the PARMS
option value. The length of the PARMS option value should be the length
of all the parameters which is 85 in this case.
Here are some other things you can try.
1) Add the SHELL option and then specify the entire command and its
parameters in the COMMAND option and don't specify the PARMS option.
In the STAX job, specify <command mode="'shell'">command</command> where
command = 'C:\N4\TEST_Apps\xps\NavisXPS -d
"C:\Projects\apex_2_1-rel\N4\stafTests\TestData\GCT\Chassis_Gate"
-STAFTEST SERVER'
Note that you may find it easier to debug by submitting the STAF PROCESS
START request via the command line (unless the STAX job is doing a bunch
of setup work for it). For example, if submitting a STAF PROCESS START
request via the command line (note that I escaped the " with \" so that I
could enclose the entire command value with double quotes). Also, I added
the WAIT RETURNSTDOUT STDERRTOSTDOUT options to wait for the command to
complete and to return anything the command wrote to stdout/stderr in the
result:
STAF local PROCESS START WAIT RETURNSTDOUT STDERRTOSTDOUT SHELL COMMAND
"C:\N4\TEST_Apps\xps\NavisXPS -d
\"C:\Projects\apex_2_1-rel\N4\stafTests\TestData\GCT\Chassis_Gate\"
-STAFTEST SERVER"
2) When you ran the command from a command prompt, did you need to run it
from a particular directory for it to work? If so, then specify a working
directory using the WORKDIR option (or <workdir>workdir</workdir> within
your <process> element after the <command>/<parms> element). For example,
if the working directory needed to be C:\N4\TEST_Apps\xps, then specify:
STAF local PROCESS START WAIT RETURNSTDOUT STDERRTOSTDOUT WORKDIR
C:\N4\TEST_Apps\xps SHELL COMMAND "C:\N4\TEST_Apps\xps\NavisXPS -d
\"C:\Projects\apex_2_1-rel\N4\stafTests\TestData\GCT\Chassis_Gate\"
-STAFTEST SERVER"
3) Add the SAMECONSOLE option to the PROCESS START request.
In the STAX job, add <console use="'same'"/> as the last sub-element
within your <process> element.
Note that you may find it easier to debug by submitting the STAF PROCESS
START request via the command line (unless the STAX job is doing a bunch
of setup work for it). For example:
STAF local PROCESS START WAIT RETURNSTDOUT STDERRTOSTDOUT SAMECONSOLE
SHELL COMMAND "C:\N4\TEST_Apps\xps\NavisXPS -d
\"C:\Projects\apex_2_1-rel\N4\stafTests\TestData\GCT\Chassis_Gate\"
-STAFTEST SERVER"
4) Check if there is anything else different in the environment when you
run this command from a command prompt without STAF versus when you run it
via STAF. Note that when it is run via STAF, the command is run in the
environment in which STAFProc is running so if there are any environment
variables that this command depends upon they must be set in the
environment in which STAFProc is running, or by specifying the ENV
option(s) on the PROCESS START request (aka <env> sub-element).
--------------------------------------------------------------
Sharon Lucas
IBM Austin, luc...@us.ibm.com
(512) 286-7313 or Tieline 363-7313
From: Tennis Smith <tennis_sm...@yahoo.com>
To: Sharon Lucas/Austin/IBM@IBMUS
Cc: staf-users@lists.sourceforge.net
Date: 07/19/2011 03:40 PM
Subject: Re: [staf-users] Trace <stafcmd> ?
Sent by: tennis.n.sm...@gmail.com
Thanks! That's exactly what I needed.
Here is what I found. Please bear with me, I'm debugging someone else's
app:
To start the application, this is what is needed on the command line.
This does *not* cause a crash:
C:\N4\TEST_Apps\xps\NavisXPS -d
"C:\Projects\apex_2_1-rel\N4\stafTests\TestData\GCT\Chassis_Gate"
-STAFTEST SERVER
Here is the same command from the trace when sent via staf. This will
cause a crash:
20110719-12:58:55;4856;00000001;PROCESS Service Request - Client:
local://local, Handle: 38, Process: STAX/Job/3, Request: start command
C:\N4\TEST_Apps\xps\NavisXPS parms :85:-d
"C:\Projects\apex_2_1-rel\N4\stafTests\TestData\GCT\Chassis_Gate"
-STAFTEST SERVER
- Is there anything odd about the second example we should change?
- Does staf require the colon-length-colon (:85:)? If so, should the
length (85) include everything up the end of "SERVER", or just up to the
closing quote?
We are using staf ver. 3.4.1 on WinXP.
Thanks,
-T
On Tue, Jul 19, 2011 at 12:17 PM, Sharon Lucas <luc...@us.ibm.com> wrote:
Yes, STAX submits a STAF service request for each <stafcmd> it processes.
STAF provides a TRACE service that allows you to enable tracing for STAF
service requests submitted so that you can see the STAF service request
submitted. The TRACE service also allows you to set the trace output
destination.
See section "8.18 Trace Service" in the STAF User's Guide at
http://staf.sourceforge.net/current/STAFUG.htm#HDRTRACESRV for more
information. You will want to enable the ServiceRequest tracepoint on the
machine that you specified for the <location> sub-element for <stafcmd>.
The ServiceRequest tracepoint causes a trace message to be generated for
every incoming service request before it is processed by the service.
For example, assuming the stafcmd element's <location> sub-element
specified machine 'client1.company.com', you could enable tracing for the
ServiceRequest tracepoint on this machine as follows:
STAF client1.company.com TRACE ENABLE TRACEPOINT "ServiceRequest"
Assuming the stafcmd element's <service> sub-element specified service
'FS' (though it could be any STAF service), you could enable tracing for
only service 'FS' (and not all the other STAF services) on this machine as
follows:
STAF client1.company.com TRACE DISABLE ALL SERVICES
STAF client1.company.com TRACE ENABLE SERVICE FS (Instead of FS,
specify the service in your <stafcmd> element that you want to trace)
And you can specify STAF tracing to go to file C:\temp\staf.trc (or
whatever file you wanted) on machine client1.compnay.com as follows:
STAF client1.company.com TRACE SET DESTINATION TO FILE C:/temp/staf.trc
Now that tracing is set up on client1.company.com (or whatever the name of
your Windows machine where the <stafcmd> is running), you can recreate the
problem by running your STAX job and then check the STAF trace output in
file C:\temp\staf.trc on machine client1.company.com.
--------------------------------------------------------------
Sharon Lucas
IBM Austin, luc...@us.ibm.com
(512) 286-7313 or Tieline 363-7313
From: Tennis Smith <tennis_sm...@yahoo.com>
To: staf-users@lists.sourceforge.net
Date: 07/19/2011 01:44 PM
Subject: [staf-users] Trace <stafcmd> ?
Hi,
I'm getting a crash on a win XP app called by a stax test. It appears
one of the parameters passed to it is somehow corrupted. Is there any way
to trace <stafcmd> so we can see exactly what is being passed?
--
Tks,
-Tennis
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
staf-users mailing list
staf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/staf-users
--
Tks,
-Tennis
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
staf-users mailing list
staf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/staf-users
