XMLSERVICE Control option needs "*sbmjob" specified to submit the XTOOLKIT job

[rodflohr]

This issue was observed in Zend Server 8.5.3, shipping XMLSERVICE 1.9.1 and IBM i Toolkit 1.6.0.

To reproduce: Create a new stateful connection.

Expected result: A job named XTOOLKIT should be submitted in subsystem ZENDSVR6.

Actual result: A job named QSQSRVR (XMLSERVICE if 1.9.3) is spawned in subsystem QSYSWRK. (A spawned job is different than a submitted job. These jobs inherit properties from the parent, and in the case of these jobs, they use the jobd from the QSQSRVR parent, rather than the ZSVR_JOBD jobd that is used for XTOOLKIT jobs. A spawned job is the default if the control does not specify *HERE or *SUBMIT. We may want to have further discussion about whether to keep this option available.)

Workaround: Include 'customControl' => "_sbmjob" in the setOptions(). Example:
$ToolkitConn->setOptions(array('stateless'=>false, 'InternalKey'=>"/tmp/$user", 'customControl' => "_sbmjob"));

Possible code to fix: In ToolkitService.php, in the getControlKey() function, there is this:

    if ($this->isStateless()) {
        $key .= " *here";

    } else { 
        // not stateless, so could make sense to supply *sbmjob parameters for spawning a separate job.
        if( trim($this->getOption('sbmjobParams') ) != '' ) {
           $sbmjobParams = $this->getOption('sbmjobParams');
           $key .= " *sbmjob($sbmjobParams)";
        } //(if subsystem *sbmjob specified)

    } //(if stateless)

Notice that if the job is not stateless, the '*sbmjob' control key is only set if there are sbmjob parameters in the options. It probably needs to be set even if no parameter options. So I would likely set the key to append *sbmjob right after the 'else', and then add in the parameters if there are any. I have not tested this, but what I am proposing is this:

    if ($this->isStateless()) {
        $key .= " *here";

    } else { 
        $key .= " *sbmjob";  // set the control key here
        // not stateless, so could make sense to supply *sbmjob parameters for spawning a separate job.
        if( trim($this->getOption('sbmjobParams') ) != '' ) {
           $sbmjobParams = $this->getOption('sbmjobParams');
        //   $key .= " *sbmjob($sbmjobParams)";  // Don't set the control key
           $key .= "($sbmjobParams)";  // Just add the parameters
        } //(if subsystem *sbmjob specified)

    } //(if stateless)

This should be tested to see if it works, but also regression tested to make sure having *submit in the controls does not cause problems elsewhere. For instance, does it show up in a program call or command call, and if so does it cause any trouble.

[alanseiden]

Good idea, but, check to ensure that 'customControl' doesn't already include a *SBMJOB key before setting *SBMJOB.

[rodflohr]

Or test to see whether it matters if it is in there twice... ;-)

[alanseiden]

The *SBMJOB may contain actual parameters that we wouldn't want to lose. e.g.
*sbmjob(ZENDSVR/ZSVR_JOBD/XTOOLKIT)

[rodflohr]

Yes. That is why you put them in, if there are any. That is how I coded it. Put the *sbmjob, then if there are parameters put those as well.

If there is a situation where the customer has already put both parameters and the custom *sbmjob control, this patch should not affect them. Because, the patch will put in the same as it would have before the patch, since there are parameters. If there are parameters, the patched code works exactly the same as the unpatched code. Or at least it should. Untested, as noted.

From: Alan Seiden [mailto:notifications@github.com]
Sent: Tuesday, March 08, 2016 12:49 PM
To: zendtech/IbmiToolkit
Cc: Rod Flohr
Subject: Re: [IbmiToolkit] XMLSERVICE Control option needs "*sbmjob" specified to submit the XTOOLKIT job (#64)

The *SBMJOB may contain actual parameters that we wouldn't want to lose. e.g.
*sbmjob(ZENDSVR/ZSVR_JOBD/XTOOLKIT)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/64#issuecomment-193960480.

[alanseiden]

OK, may be fine

[rodflohr]

Maybe. Needs regression testing to be sure. May not be fine. May not even be fine to add *sbmjob as a custom control if parameters are specified, patched or not. I have no idea if it is OK to do that. Not sure why anyone would, since the submitted job probably comes up OK if there are parms.

My assertion is the patch makes no difference if both the custom control and parms are specified. Will bet a beer that is true.

From: Alan Seiden [mailto:notifications@github.com]
Sent: Tuesday, March 08, 2016 1:02 PM
To: zendtech/IbmiToolkit
Cc: Rod Flohr
Subject: Re: [IbmiToolkit] XMLSERVICE Control option needs "*sbmjob" specified to submit the XTOOLKIT job (#64)

OK, may be fine

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/64#issuecomment-193965313.

[cooperl22]

Hi.

I think I'm faced to the same issue described here.

Indeed since this repository is compatible with Composer I switched back to this one instead of my fork based on 1.6.

The problem is that the option sbmjobParams of the Toolkit class is now empty by default. This is not good and not what it is written in the toolkit.ini. Indeed by default it should be as before

ZENDSVR6/ZSVR_JOBD/XTOOLKIT

For instance when I call a program (pgmCall) which generates spools it creates a spool with the JOB QPRTJOB instead of XTOOLKIT and also no XTOOLKIT job is initialized. I'm in statefull mode.

So the question is : Why no default sbmjobParams option is set in the release 1.7.0?

As a workaround I use $toolkitObj->setOptions(['sbmjobParams' => 'ZENDSVR6/ZSVR_JOBD/XTOOLKIT']).

Thank you.

[jordiwes]

I'm working on this... do we have any good test cases for this?

[alanseiden]

@jordiwes please ask @rodflohr if you need an example

[alanseiden]

The change to sbmjobParams occurred in 1.5.1. This worked at the time, and was a good idea for compatibility with multiple versions of Zend Server (i.e. putting ZENDSVR or ZENDSVR6 in the code would limit support to a specific location and Zend Server version), but something may have changed in XMLSERVICE or elsewhere, later, that caused the behavior to change. In any case, we are going to resolve it by specifying reasonable default behavior at the toolkit level.