#528 Using SHELL option causes incorrect handle # to be returned

[David Michael Bender]

If you specify the shell option, the handle returned is
the incorrect handle (the actual handle is +1, at least
in this example). For example:

<process name="'My Test Process'">
<location>'local'</location>
<command mode="'shell'">
'java com.ibm.staf.service.stax.TestProcess 10 3 99'
</command>
</process>

The STAX Monitor is trying to query the Process's
Monitor information, but the handle it received in the
start event for the process was 202, and we get no
Process Monitor information. The process's real handle
is 203 (and if you query handle 203's Monitor
information, you get the correct data).

Removing the SHELL option corrected the problem.

[Sharon Lucas]

Logged In: YES
user_id=285070

Here are some comments on this from Charles:

This is a long standing problem with STAF (at least as far
back as when I was giving the education). The problem is
that STAF associates the new handle with the process ID,
but since you are starting a shell, the shell invokes a new
process (the one you really wanted to start). So, when the
real application registers with STAF, the PIDs don't match up
and it gets a new handle #. The fix is going likely to include
setting an environment variable of some form to indicate
which handle to use, but we'll need to be careful of security
issues. Perhaps we can associate a private "password" with
the handle, and set an environment variable in the process to
this password. Then, the registration code could read this
env variable and pass the password (probably along with the
handle # specified in another env variable) to STAFProc
(which would use it to validate the correct handle is used).
Then, the process is given that handle. That seems like it
should work. We wouldn't want the "password" to be visible
from any other STAF request though, so that nobody
could "fake us out".

[Sharon Lucas]

Logged In: YES
user_id=285070
Originator: NO

This bug is causing issues in STAX jobs when a <process> element that uses the "shell" mode is contained within a <timer> element. When the timer pops, the timer element submits a PROCESS STOP HANDLE <Handle> request but the process isn't really stopped since it's not using the right handle. For example, the following STAX job run on Windows demonstrates the problem:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE stax SYSTEM "stax.dtd">

<stax>

<defaultcall function="Main"/>

<script>
machine = 'staf1ax'
</script>

<function name="Main">
<sequence>

<log message="1">'Start timer'</log>

<timer duration="'5s'">
<sequence>

<process name="'Notepad'">
<location>'local'</location>
<command mode="'shell'">'notepad A'</command>
</process>

</sequence>
</timer>

<if expr="RC == 0">
<log message="1">'Task completed before timer popped'</log>
<else>
<log message="1">'Task was still running when timer popped'</log>
</else>
</if>

</sequence>
</function>

</stax>

I'm increasing the priority of this bug.

[Sharon Lucas]

Logged In: YES
user_id=285070
Originator: NO

The problem I commented on is a different problem so I'll open a different bug.

[David Michael Bender]

As part of Bug #2549437 "Typo in STAX User's Guide <process-action> example", added information to the STAX User's Guide <process-action> section about this problem (including examples of sending queued messages to the process using the handle number or the handle name, depending on the <command> mode attribute value. So, when bug 1172800 is fixed, this information should be removed from the STAX User's Guide.

[Sharon Lucas]

Neha Dharni ran into another variation of this bug that is causing a problem. Neha has a <process> element as follows in a STAX job:

<process name="'Testing files">
<location>machineLocation</location>
<command mode="'shell'">'start /B /WAIT /HIGH "%s" "%s"' % (os.path.basename(testHarness), testHarness)</command>
<parms>"%s" %(testHarnessParams)</parms>
<var>'SharedSTAXJobId=%s' % (STAXJobID)</var>
<var>'STAXService=%s' % (STAXServiceName)</var>
<var>'STAXMachine=%s' % (hostMachine)</var>
<stderr mode="'stdout'"></stderr>
<returnstdout/>
</process>

When this process is run, SharedSTAXJobId, STAXService and STAXMachine variables are not set.

If the shell mode is removed from <command>, e.g. <command> "%s"' % (testHarness)</command>, then the STAF variables are set successfully.

Here's a simple example (just using a STAF PROCESS START request) that illustrates the problem:

- If don't use the SHELL option, the following works:

C:\&gt;STAF local PROCESS START COMMAND "STAF local VAR RESOLVE STRING {MyVar}" VAR MyVar=XYZ RETURNSTDOUT STDERRTOSTDOUT WAIT
Response
--------
{
Return Code: 0
Key : <None>
Files : [
{
Return Code: 0
Data : Response
--------
XYZ

}
]
}

- If the SHELL option is specified, the following fails with RC 13:

C:\&gt;STAF local PROCESS START SHELL COMMAND "STAF local VAR RESOLVE STRING {MyVar}" VAR MyVar=XYZ RETURNSTDOUT STDERRTOSTDOUT WAIT
Response
--------
{
Return Code: 13
Key : <None>
Files : [
{
Return Code: 0
Data : Error submitting request, RC: 13
Additional info
---------------
Variable resolution failed for string: {MyVar}

You are trying to resolve a variable that does not exist: MyVar

}
]
}

This problem needs to be resolved.