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.
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:
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:
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.