JAMS for zOS incorporates zOS job scheduling into the JAMS Scheduler platform. JAMS supports cross platform job dependencies that include zOS jobs running in JES2 batch.
JAMS provides the ability to store a JCL source in its internal database. The JCL then becomes a part of the JAMS Job Definition along with other parameters and information needed to run the job.
The JAMS Scheduler can support multiple zOS hosts and track Job dependencies between them and non-zOS hosts.
The JAMS Scheduler retrieves all job related output from the JES Spool. This includes any DD statements with SYSOUT held on the spool. The output appears in the JAMS log and can be used by operations administrators to debug problems and, if necessary, restart the jobs.
JAMS for zOS parses the job output and provides job success or failure information for the JAMS Scheduler to react and report on a variety of message codes, including HASP and return code analysis.
JAMS for zOS uses JESINTERFACELEVEL 1 and doesn’t require special customization of Parmlib settings.
JAMS for zOS uses zOS FTP with JES and requires no additional mainframe software installation.
JAMS for zOS automatically purges the job output files for the JES2 Spool after each Job has completed and been retrieved.
The JAMS Scheduler can recover its connection to JES if it is lost due to a network outage or other problem, even when a job is in the middle of executing on zOS. In the event of failure on the JAMS server, JAMS can restart for that specific job and seamlessly recover.
JAMS interfaces with JES as a TSO user. The TSO login ID is interpreted by JAMS as a valid JAMS user and encrypted on the JAMS side and controlled by RACF on the zOS side.
JAMS for zOS becomes part of the integrated capabilities of the JAMS Scheduler across different platforms allowing it to control jobs based on dependencies on all supported hosts.
Setting up a zOS job is now as easy as defining any other JAMS Job.
A special option in the JOB definition includes a listing of JOBS on the JES Spool allowing a job to rerun on the JAMS side for output recovery.
Suppose an organization has the need to reliably synchronize data from an OLTP system based on a MS SQL Server or Oracle with a mainframe-based database. This scenario is easily implemented with JAMS for zOS.
In order to accomplish this the JAMS Scheduler would initially run a job, based on an event, that generates files comprised of data extracted from a MS SQL Server database. It would then upload those files to the zOS platform via FTP before submitting JCL through JAMS for zOS. These uploaded files would then update a mainframe database. The reverse scenario is just as easy where a MS SQL Server is updated with files generated by the mainframe.