z/OS Integration Pack

JAMS for z/OS incorporates z/OS Job scheduling into the JAMS platform and requires nothing to install on the z/OS host. When creating the agent used with the z/OS integration, you must select the Passive agent type and the zOS Type of platform.

Use this step-by-step guide to define a new z/OS Job using the JAMS Client.

Setting up the Connection with JAMS as a TSO User

To set up a connection with JAMS, you will need to first define a TSO user on the mainframe as well as in JAMS (from the Credentials shortcut).

  1. Open the Credential Definitions view from the JAMS Menu.
  2. Click the Add button on the Control Bar. The JAMS Credential definition dialog opens.
  3. Set the Credential Name, Logon As, Password, and Password Confirmation values.
  4. Click OK. By default, JAMS will open the full Credential Definition dialog after the Credential definition is initially saved.
  5. On the Security tab of the Credential dialog, Add the ACE for the TSO user. This user must have login rights as well as rights to execute items that will be added in later JAMS jobs.
  6. Save and Close the Credential definition.

For further information on adding a new username in JAMS, go to the topic: JAMS Security: Working with User Definitions.

JAMS interfaces with JES as a TSO user. The TSO login ID is interpreted by JAMS as a valid JAMS User, which is encrypted on the JAMS side and controlled by RACF on the z/OS side. The TSO user must have permissions to submit and receive Jobs on both platforms and the TSO username must contain 7 characters or less.

On the JAMS side, the z/OS Integration must be installed on the JAMS Server.

Setting up a z/OS Job in JAMS

NOTE: The Job name being referred to within the JCL needs to be the same as the Execute As user plus one character. If your credential user in JAMS is called “IBMUSER”, the Job name within the JCL would need to be “IBMUSERx” (where x is A-Z or 0-9).
  1. Select the desired folder for the z/OS Job, and then ensure the Job Definitions tab is selected.    
  2. Click the Add button from the Control Bar to open the Add a New JAMS Job Definition dialog.
  3. In the dialog, give the new Job a Name, Description (optional), and Execution Method.
    In this case, select z/OS to create a z/OS Job.
  4. By default, the full Job Definition dialog will open when the Job is initially saved.
  5. Click OK. The Job Definition dialog will open.
  6. Define Schedule Items, Parameters, Security, Properties, and Documentation as desired.
    NOTE: An Execute As property should be configured with the previously defined TSO user.
    NOTE: An Agent property should be configured with the Mainframe Agent hostname or IP address.
  7. On the Source tab, insert the JCL code.
  8. Save and Close the Job definition.

Properties to Configure Connection Retries

A z/OS Job in JAMS has several properties that you can configure to control the number of connection retries and the time in between each retry. The z/OS Max Ftp Retry is useful if FTP exceptions have occurred during the FTP connection. The z/OS Max Status Retry option is useful if z/OS is holding Jobs in a state, such as INPUT, and is delayed in sending responses back to JAMS.

Option Description
z/OS Max Ftp Retry Enter the maximum number of retries that JAMS will run to get a successful FTP connection. The default is zero, which sets JAMS to send an unlimited number of retries until a successful FTP connection is made.
z/OS Ftp Retry Interval Enter the time to wait between each FTP retry. The default is 500 milliseconds.
z/OS Max Status Retry Enter the maximum number of retries that JAMS will run to get a z/OS status response for the JAMS Job that was sent. This applies to the initial connection to the mainframe. The default is zero, which sets JAMS to send an unlimited number of retries until it receives a response from z/OS.
z/OS Status Retry Interval Enter the time to wait between each retry for z/OS status response. The default is 5,000 milliseconds.

How does JAMS run a Mainframe Job?

Jobs are stored on an FTP server located on the mainframe using a proprietary IBM-based FTP language. JAMS communicates with the mainframe using this FTP language. Once a Job is executed in JAMS, an FTP connection is opened to the FTP Daemon in JES and the Job is sent to the mainframe and executed.

JAMS monitors the Job spool output and waits for the Job to complete by polling the FTP connection. Once the output files are complete, JAMS purges the files from the JES spool.

Steps can be run in JES in the same way as tasks in a JAMS Sequence. JCL defines the behavior of the Job depending on what is happening with a particular Job task.

What Information does JES Return?

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

JAMS for z/OS parses the Job output and provides job success (“0”) or failure information for the JAMS Scheduler to react and report on a variety of message codes, including HASP and return code analysis.

What happens when a Job fails?

If a Job fails due to a network outage or other problem, all relevant information is included in the output and also displayed in the JAMS log. Customization of these messages can be set using a configuration file.

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.

JAMS for z/OS Capabilities

Manages and Submits JCL Files to JES2 on z/OS for Execution

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.

Schedules Jobs with Dependencies on Multiple z/OS Hosts

The JAMS Scheduler can support multiple z/OS hosts and track Job dependencies between them and non-z/OS hosts.

The JAMS Scheduler Retrieves and Displays the Job Output

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.

Includes Automatic Determination for all Job Results

JAMS for z/OS 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.

Utilizes Standard JES Settings

JAMS for z/OS uses JESINTERFACELEVEL 1 and doesn’t require special customization of Parmlib settings.

Requires No installation on z/OS Hosts

JAMS for z/OS uses z/OS FTP with JES and requires no additional mainframe software installation.

Provides Automatic Job Purging Capabilities

JAMS for z/OS automatically purges the job output files for the JES2 Spool after each Job has completed and been retrieved.

Provides Reliable Tracking of Jobs Running on the Mainframe

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 z/OS. In the event of failure on the JAMS server, JAMS can restart for that specific job and seamlessly recover.

Uses a Secure TSO User Login

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 z/OS side.

Provides Full Integration with the JAMS Scheduler

JAMS for z/OS 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.

JAMS for z/OS is Easy to Set Up

Setting up a z/OS job is now as easy as defining any other JAMS Job.

Provides a Listing of Pending Jobs on the z/OS Spool

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.

Scenario: Synchronizing Data with JAMS for z/OS

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 z/OS.

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 z/OS platform via FTP before submitting JCL through JAMS for z/OS. 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.

Related Topics