Replacing an Active Control-O Monitor

When a Control‑O monitor is started using operator command S CONTROLO, and a Control‑O monitor is already active in the computer, the current Control‑O monitor passes control to the new Control‑O monitor and then shuts down. It is not necessary to reload the rule tables; they are passed from the current monitor to the new one.

To clean (erase) all Control‑O tables from memory, shut down the Control‑O monitor. This is not usually done, except in an emergency.

The following explains why it is not necessary to reload the rule tables:

• When Control‑O is started, the user must tell Control‑O which rule list to load. Control‑O also loads the Global AutoEdit variable pools.
• When the user starts Control‑O while Control‑O is already active, the new Control‑O inherits the rules and Global AutoEdit variables that were in use by the previous Control‑O. It also inherits the subsystem and extended MCS consoles that the first Control‑O allocated, and uses the areas in the Extended Common Service Area (ECSA) allocated and linkage index (for cross memory services).
• The user does not lose settings from the previous Control‑O session when one Control‑O is replaced by another.

This mechanism is used in the following situations:

1. When one of the monitor subtasks has an error (internal error or an abend), the Control‑O monitor automatically attempts to recover. It tries to replace the old monitor with a new one, without stopping its activity. Control‑O performs this process only one time. If another error occurs, Control‑O is then terminated.
2. If starting Control‑O before JES, start it with SUB=MSTR. A started task with SUB=MSTR has no SYSOUTs. When JES is up and running, it is recommended to replace the first Control‑O with a new one, so the monitor is a normal started task with SYSOUTs.
3. To apply maintenance or a specific PTF to the Control‑O monitor (after a SMP/E apply is done), start a new monitor without stopping the old monitor, so that all of the monitor’s internal modules are refreshed.

   Note: The Control‑O executor modules that were loaded into ECSA (CTOWTO and CTOAIDT) are not refreshed in this manner. Control‑O modules can be refreshed by issuing a new MODIFY command to Control‑O (RELOAD=CTOWTO, CTOAIDT, and so on).

   When Control‑O is active for many days, it is recommended to refresh the monitor for the following reasons:

   • Storage fragmentation may occur in the Control‑O address space.
   • The JOBLOG and SYSPRINT may become lengthy and difficult to follow.

   This process is known as swapping Control‑O monitors.

   Note: Storage in ECSA, allocated by the first Control‑O, is used by the new Control‑O. This storage is displayed as orphan storage on the ECSA monitor, in OMEGAMON for MVS, BMC’s MAINVIEW or TMON for MVS. The customer must not release these areas, because doing so may damage the system and cause an IPL