|
|
|
|
|
A configuration in which two Control‑M systems operate is common because many sites install a Control‑M production system and a Control‑M test system. We recommend operating a separate Control‑M test system for testing new versions or options before applying them in the Control‑M production system. Usually, the Control‑M production system and Control‑M test system are separate systems that use separate libraries, separate databases, different JCL procedures, and so on.
In some cases, there may be good reasons for operating two or more Control‑M production systems. For example, a service bureau may need to provide distributed scheduling for two or more clients.
Two Control‑M systems can communicate with each other by scheduling special jobs. For example, Control‑M system A may schedule a special job that invokes utility IOACND, which adds a prerequisite condition to the IOA Conditions file base of Control‑M system B. This prerequisite condition, in turn, triggers the submission of a job by Control‑M system B.
Subject to system resource limitations any number of Control‑M systems can be operated concurrently on a single mainframe.
For additional information about how to activate more than one Control‑M monitor, see the Control‑M chapter in the INCONTROL for z/OS Installation Guide: Installing.
Each Control‑M system uses a separate CMEM subsystem. Subject to system resource limitations, any number of CMEM subsystems can be operated concurrently. However, a job can be handled by only one CMEM subsystem.
Different (several) CMEMs can be used to acknowledge job-arrival or job-ended events for a job. However, use only one CMEM to acknowledge ON DSNEVENT or ON STEP events.
Parent Topic |