Overview of job tracking on z/OS®

This chapter describes briefly how HCL Workload Automation for Z tracks work on the host. If an operation is not tracked, there is normally a problem with the HCL Workload Automation for Z configuration or the initialization statements.

HCL Workload Automation for Z uses event records to track the workload. Most event records are generated automatically as a job progresses through the system, but they can also be generated manually. You can use HCL Workload Automation for Z TSO commands and HCL Workload Automation for Z subroutines to report event information to HCL Workload Automation for Z, both manually and automatically. You can:
  • Request a backup of the current plan or JCL repository using the BACKUP TSO command or EQQUSINB subroutine.
  • Make a special resource available or unavailable using the SRSTAT TSO command or EQQUSINS subroutine.
  • Change the status of an operation using the OPSTAT TSO command or EQQUSINT subroutine.
  • Update the user data field of an operation in the current plan using the OPINFO TSO command or EQQUSINO subroutine.
  • Change the status of a workstation in the current plan using the WSSTAT TSO command or EQQUSINW subroutine.
  • Request any of these changes using the EQQUSIN subroutine or the application programming interface (API) for HCL Workload Automation for Z.
This is how the event information is passed to HCL Workload Automation for Z:
  • For z/OS® jobs and started tasks, z/OS® calls the SMF and JES exits at certain stages in the life of a job. For example, the job initiation exit IEFUJI is called whenever a job starts. HCL Workload Automation for Z code in the exit collects information about the event and passes it to the event-creation module, EQQSSCMx, through the z/OS® subsystem interface. Relevant information for a job that has started would include the job name and number, and its starting date and time.
  • All HCL Workload Automation for Z address spaces start a submit task, which initiates work for the workstation destination that represents the system that the controller or tracker is started on. When the submit task starts work, it uses EQQSSCMx to create initialization events, depending on the type of work to be started. Different initialization events are created for batch jobs, started tasks, write-to-operator (WTO) operations. Submit-checkpointing events are created for all work that HCL Workload Automation for Z submits, except operations that are routed to a user-defined destination.
  • If you generate an event using the BACKUP, OPINFO, OPSTAT, WSSTAT, or SRSTAT commands from the TSO environment or from the EQQEVPGM batch program, the parameters are checked and then passed to the event-generation module, EQQSSCMx, through the z/OS® subsystem interface.
  • You can generate an event if you write a program that passes parameters to the EQQUSIN, EQQUSINB, EQQUSINS, EQQUSINO, EQQUSINW, or EQQUSINT subroutines. The subroutine checks the parameters and passes them to the event-generation module, EQQSSCMx, through the z/OS® subsystem interface.
When the events have been created, this is how they are passed to the controller:
  1. EQQSSCMx uses the information to build an event record and places the record into the event writer queue in ECSA.

    This processing can take place as soon as the z/OS® subsystem interface is started. It is not necessary for HCL Workload Automation for Z itself to be active. If HCL Workload Automation for Z is not active (in particular, if the event writer subtask is not active), event records stay in the event writer queue until the event writer starts and processes them.

    Event records are generated for all z/OS® jobs and started tasks, even though they might not be relevant to a particular HCL Workload Automation for Z address space. It is not possible for the programs creating the event records to determine if a particular job is relevant to a particular HCL Workload Automation for Z address space. The event creation programs reside in z/OS® common storage and do not belong to, or have access to, the data or resources of any HCL Workload Automation for Z address space that might be running on the same system or some other system.

  2. The event-writer subtask of the tracker reads event records from the event writer queue and writes them to an event data set. They can be filtered at this stage by the EQQUX004 exit, if this is required for performance reasons.
  3. Events are transmitted to the controller by an event reader function, which is either a function of the event writer, or is a separate event reader task. An event writer can use an XCF, NCF or TCP/IP connection to transmit events to the controller. Where a separate event reader is used, the event reader can be active at the controller, or at a tracker that is connected to the controller through XCF or NCF. If the event writer is active but there is no connection to the controller, or if the event reader is not active, events stay in the event data set until the required function is available.
  4. The event manager subtask that is started at the controller processes the events, and HCL Workload Automation for Z takes the relevant action.
Events are never lost, if these conditions are satisfied:
  • The event writer queue in ECSA is large enough to hold all the event records that might be created while the event writer is not active.
  • The event data set is large enough to hold all the event records that might be created while a connection to the controller is lost, or an event reader is not active.