Introducing the z/OS Agent and Gateway Adapter

The master schedule comprises the scheduling criteria associated with jobs, JCL, shell scripts, programs, and commands (workloads). The master schedule determines on which machines workloads will run. When you employ agent machines, the location of the machines to execute the workload can remain independent of the machine containing the master schedule. The only prerequisite for the master/agent relationship is that the machine acting as the master must be on the same TCP/IP network as the machines serving as agents.

Evolution of the Platform

As an IBM mainframe platform, z/OS has been around for a long time even if the name itself is recent.

The original name that IBM gave its mainframe operating system in 1974 was MVS standing for Multiple Virtual Storage. In 1996, IBM added a set of utilities to the MVS program and renamed the operating system OS/390. The latest incarnation of IBM’s mainframe system was enhanced and renamed z/OS in 2001 and this is the name used throughout this manual.

Architecture of the Agent and Adapter for z/OS

There are two components of the Adapter for z/OS. Each component is an independent entity fulfilling different functions. Depending upon your needs, you do not necessarily need both components.

One component is the agent that runs under OpenMVS (OMVS) utilizing Unix System Services (USS) provided by the z/OS operating system. Through the agent, the TA master can submit JCL (JES2), run system (console) commands and execute programs and shell scripts (OMVS/USS environment). The agent transfers output to the TA master and services file dependencies for z/OS Unix files and datasets (exist/non-exist only for datasets).

The second component is the Gateway for z/OS that is comprised of additional functionality in the Agent and a new z/OS Started Task called the Tidal Data Server (TDS) which interacts directly with the z/OS System Management Facility (SMF). The Gateway TDS operates in the background relaying job/job step information to the Agent (via TCP/IP) by monitoring SMF type 30 records that log the stages in the life cycle of a z/OS job. This allows TA to track dependencies based on condition codes of any submitted z/OS job. The Gateway does not alter the contents of any SMF data.

Master/Agent Architecture

The master/agent architecture has become increasingly popular in managing distributed systems. It offers many advantages to companies needing to provide centralized support and administration for workloads that span not only multiple machines and platforms, but often multiple locations. The TA master/agent architecture consists of one (or more) machines that contain a master schedule, and one or more agent machines that execute workloads on behalf of the master schedule. The master schedule comprises the scheduling criteria associated with jobs, JCL, shell scripts, programs, and commands (workloads). The master schedule determines on which machines workloads will run. When you employ agent machines, the location of the machines to execute the workload can remain independent of the machine containing the master schedule. The only prerequisite for the master/agent relationship is that the machine acting as the master must be accessible via TCP/IP to the machines serving as agents, and vice versa.

Benefits of the Master/Agent Architecture

The master/agent architecture provides several benefits for customers who need to centrally manage their daily job scheduling operations.

You only need to maintain a single master schedule.

This reduces the effort of individual(s) performing the job scheduling role.
You can offload workloads to multiple machines.

This increases the efficiency of your company's computing power.
You can view and control all job scheduling operational activity from a single production status window.

This condenses the production schedule into a single image that you can manage from a single location, regardless of the number, type or location of the machines executing the workload.

One of the primary benefits of agent software is that workloads are not interrupted or aborted on the agent if the master schedule or the network shared between the master schedule and the agent becomes unavailable. The agent continues to process any job it is working on if a network connection fails.

TA Agent for z/OS Functions

The TA z/OS agent component of the z/OS adapter provides these services to a master:

Submits JCL (JES2)
Executes USS (OMVS) scripts and programs
Executes system (console) commands
Tracks current state and status of TA submitted jobs
Monitors file dependencies (exist/non-exist for datasets)
Transfers job output to the master

This agent is implemented using TA Java agent technology and is stored along with configuration and logging files in the z/OS Unix file system.

The z/OS agent uses TCP/IP to communicate with the TA master and the Tidal Data Servers (SMF monitors).

z/OS Gateway Adapter Services

The z/OS Gateway Adapter functionality is re-written in this release. It is now comprised of functionality added to the z/OS Agent and a new component – Tidal Data Server (TDS), which runs as a Started Task. The two components of the z/OS Gateway Adapter provide the same functionality as the previous Gateway Adapter. The Agent provides the external interface between z/OS and the TA Master, SMF history and production day management functions. The TDS component utilizes a single Started Task to monitor and provide SMF data upstream to the Gateway functionality in the Agent.

The Agent can be brought up with the functionality of Agent only, Gateway only (requires TDS) or both in a given instance. This is controlled by new parameters in the Agent configuration.

Gateway Tidal Data Server (TDS) Functions

The Gateway TDS component of the z/OS adapter provides these features:

Installs without an IPL
Sysplex support
Monitors SMF records without alteration
Supports z/OS 2.2 and above

The Gateway Tidal Data Server component uses one Started Task:

TDSPROD