Skip to content

1.2.1 - Release Highlights

Changes affecting tests running locally or on the Galasa Service

  • z/OS Batch Manager: Added a new submitJobWithSuppliedJobcard(String jcl) method to the IZosBatch interface that submits JCL which already contains its own JOB statement, such as a member of a JCL library. Previously the manager always generated a JOB statement and put it in front of the supplied JCL, so JCL that contained its own JOB statement was rejected by JES with a JCL error. Tests no longer need to strip the JOB statement and its continuation records from the JCL, or re-express its attributes using a ZosBatchJobcard. This is supported by both the z/OS MF and RSE API implementations of the z/OS Batch Manager. See the z/OS Manager documentation for examples.
  • The job name is taken from the JOB statement in the supplied JCL and is used to track the job, so waitForJob(), getRetcode() and the retrieval of spool files work in the same way as for other jobs. A Galasa provisioned job name is not used.
  • The JOB statement can be continued over several records. The first record that is not blank or a comment (//*) must be the JOB statement. If a valid JOB statement is not found, a ZosBatchException is thrown and the JCL is not submitted.
  • A ZosBatchJobcard cannot be used to override values in the JOB statement, and the default input class, message class and message level CPS properties are not applied. Everything required must be specified in the JOB statement.
  • If the zosbatch.batchjob.[imageid].use.sysaff CPS property is true, the manager still adds a /*JOBPARM SYSAFF=[imageid] record, immediately after the last record of the JOB statement. It does not add the record if the supplied JCL already contains a /*JOBPARM record that specifies SYSAFF=.
  • The existing submitJob methods are unchanged. The JCL passed to them must still not include a JOB statement.