Hi Sharon,
See inline.
-T
On Tue, Jul 19, 2011 at 2:27 PM, Sharon Lucas <luc...@us.ibm.com> wrote:
> 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'
>
> You were right about lotsa setup going on. Had to use <command>. When
submitted, <process> fails and returns an RC of 1.
The trace output looks like this:
20110720-20:22:25;4896;00000001;PROCESS Service Request - Client:
local://local, Handle: 22, Process: STAX/Job/2, Request: START NOTIFY ONEND
KEY 1 SHELL COMMAND :117:'C:\N4\TEST_Apps\xps\NavisXPS -d
"C:\Projects\apex_2_1-rel\N4\stafTests\TestData\GCT\Chassis_Gate" -STAFTEST
SERVER '
The code looks like this:
<script>
from com.ibm.staf import STAFUtil
theCmd = "'%s %s '"%(xpsPath,xpsParams)
print "cmd="+theCmd
</script>
...
<process>
<location>xpsMachineName</location>
<command mode="'shell'">theCmd</command>
</process>
Here is the output of the 'print' in the <script> section. This comes from
the stax job log:
20110720-20:22:25 Info cmd='C:\N4\TEST_Apps\xps\NavisXPS -d
"C:\Projects\apex_2_1-rel\N4\stafTests\TestData\GCT\Chassis_Gate" -STAFTEST
SERVER '
Any ideas of what may be going on?
-T
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*<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*<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* <http://client1.company.com/>',
> you could enable tracing for the ServiceRequest tracepoint on this machine
> as follows:
>
> STAF *client1.company.com* <http://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* <http://client1.company.com/> TRACE DISABLE ALL
> SERVICES
> STAF *client1.company.com* <http://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*<http://client1.compnay.com/>as follows:
>
> STAF *client1.company.com* <http://client1.company.com/> TRACE SET
> DESTINATION TO FILE C:/temp/staf.trc
>
> Now that tracing is set up on
> *client1.company.com*<http://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* <http://client1.company.com/>.
>
> --------------------------------------------------------------
> Sharon Lucas
> IBM Austin, *luc...@us.ibm.com* <luc...@us.ibm.com>*
> **(512) 286-7313* <%28512%29%20286-7313> or Tieline 363-7313
>
>
>
>
> From: Tennis Smith <*tennis_sm...@yahoo.com*<tennis_sm...@yahoo.com>
> >
> To:
> *staf-users@lists.sourceforge.net*<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/*<http://www.accelacomm.com/jaw/sfnl/114/51385063/>
> _______________________________________________
> staf-users mailing list*
> **staf-users@lists.sourceforge.net* <staf-users@lists.sourceforge.net>*
> **https://lists.sourceforge.net/lists/listinfo/staf-users*<https://lists.sourceforge.net/lists/listinfo/staf-users>
>
>
>
>
> --
> Tks,
> -Tennis
>
--
Tks,
-Tennis
------------------------------------------------------------------------------
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
_______________________________________________
staf-users mailing list
staf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/staf-users
