This section describes the Control-M/Assist environment data flow and ties together all the Control-M/Assist components into a single framework.
Step 1 – Jobs are submitted for execution on the z/OS environment externally to Control-M. The jobs can be submitted by scheduling products or by any other alternative method (TSO submit command, user programs, and so on). After jobs are submitted, they arrive on the JES spool.
Step 2 – CMEM facility captures the job arrival events defined by the CMEM rule definitions that were activated (loaded to CMEM memory via an order/force command or via operator modify command). Using the action DO FORCEJOB that is specified in the CMEM rules, the jobs definitions are forced into the Active Jobs File and become on spool jobs. For more details, see On Spool jobs.
Step 3 – After the CMEM rule brings the external job under the control of the Control-M monitor, Control-M releases the job (if held) when the runtime scheduling criteria are met, and once the job starts execution (whether the job previously required releasing or not), it is controlled by Control-M in the same way that Control-M tracks regular jobs. Control-M waits for the job to finish, reads its SYSOUT, and performs all post-processing actions defined in the job scheduling definition.
Step 4 – Communication between Control-M/EM and a Control-M for z/OS environment is established through IOAGATE and Control-M Application Server. After a connection is established via the TCP/IP or APPC communication protocol, information is transferred between Control-M/EM and Control-M for z/OS.
Step 5 – Control-M/EM, which runs on UNIX and Microsoft Windows workstations, provides centralized control of the job scheduling production environment for the entire enterprise, including the z/OS environment batch work. Users can now monitor z/OS jobs from Control-M/EM GUI panels.
