Event creation and processing

HCL Workload Automation for Z event creation and processing shows the activities that can cause events to be created and how the events are processed by HCL Workload Automation for Z. The arrows show the flow of events among programs, central storage, and DASD storage. The flow of events is described with reference to the numbering on the diagram.

1. Event information is reported in one of these ways:
   1. 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 exits collects relevant information about the event and passes it to the event-creation module, EQQSSCMJ, via the z/OS subsystem interface. Relevant information for a job that has started would include the name and number of the job, its starting date and time, and, if catalog management is active, data set information.
   2. All HCL Workload Automation for Z address spaces start a submit task. It initiates work on the system that the controller or tracker is started on and that represents the destination defined in the workstation description. When the submit task starts work, it uses EQQSSCMJ to create initialization events, depending on the work to be started. An IJ1 event is created for batch jobs, IJ2 for started tasks, IWTO for write-to-operator (WTO) operations, and IREL for release commands. Submit-checkpointing events (IJ0) are created for all work that HCL Workload Automation for Z submits, except operations that are routed to a user-defined destination ID.
   3. You provide information about the event as parameters to the BACKUP, OPINFO, OPSTAT, SRSTAT, or WSSTAT command, which is issued from the TSO environment. The parameters are checked and then passed to the event-generation module, EQQSSCMJ, via the z/OS subsystem interface.
   4. The BACKUP, OPINFO, OPSTAT, SRSTAT, or WSSTAT command is run from a batch job, using the EQQEVPGM event-generating batch program. Parameters, which are input to EQQEVPGM through the SYSIN JCL statement, are checked and then passed to EQQSSCMJ.
   5. A user program provides information about the event in a parameter list and passes it to the EQQUSIN, EQQUSINB, EQQUSINS, EQQUSINO, EQQUSINW, or EQQUSINT subroutine. The subroutine checks the parameters and passes them to the event-generation module, EQQSSCMJ, via the z/OS subsystem interface.
   6. An application transaction program (ATP) passes a CREATE request to HCL Workload Automation for Z in an APP buffer through the application programming interface (API). The APPC subtask validates the buffer and then internally invokes the EQQUSIN subroutine.
2. The event-generation module, EQQSSCMJ, uses the information to build an event record and places the record in the event writer queue in ECSA.
   Note: Except for requests submitted through the API, the processing in these first two steps can take place as soon as the z/OS subsystem interface is started at IPL time. HCL Workload Automation for Z itself need not be active. If the product is not active (in particular, if the event writer subtask is not active), event records remain in the event writer queue until the event writer starts and processes them.

   A request submitted through the API must be passed to an active HCL Workload Automation for Z address space where the APPC subtask is started. If an event writer is not started in the same address space, the event must be broadcast.

   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.

3. The HCL Workload Automation for Z event-writer subtask of the tracker reads event records from the event writer queue and writes them to an event data set.
4. Events are transmitted to the controller by an event reader function. This is performed either by an event reader function of the event writer, or 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 via XCF, NCF, or TCP/IP. The event manager subtask that is started at the controller processes the events, and the relevant action is then taken by HCL Workload Automation for Z. If the event writer is active but no connection exists to the controller, or if the event reader is not active, events simply stay in the event data set until the required function is available.

Events are never lost, providing that the following two 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.