Control-O

• Overview

• Control-O Rules

• Private REGION Requirements of the Control-O Monitor

• Control-O Usage of the Common Service Area (CSA and ECSA)

• Control-O Usage of the Extended Link Pack Area

• Recommended Organization Method

• Management of Control-O Facilities

• Reacting to Events in a Sysplex Environment

• Customization of Automation Options

• Control-O and Control-M in the Same INCONTROL Environment

• Control-O/CICS Interface

• Control-O/IMS Interface

• Control-O MAINVIEW Alarm Interface

• Control-O MAINVIEW AutoOPERATOR interface

• Control-O SMS Interface

• Starting Control-O Communication Support (IOAGATE)

Overview

This chapter describes the initialization, customization, operation and administration features that are available for Control‑O.

Starting Control-O

Control‑O is usually started at an early stage of the IPL process. Once initialized, Control‑O can automate certain parts of the IPL process. To use Control‑O for automating parts of the IPL process, member COMMNDnn (where nn is either the number specified in member IEASYS in SYS1.PARMLIB, or 00) in the SYS1.PARMLIB library must contain the following command:

S CONTROLO,SUB=MSTR,OUTLIST=DUMMY[,ORDER=IPLRULES][,TYPE=IPL]

The SUB and OUTLIST parameters are required to start Control‑O before JES has been brought up. The ORDER and TYPE parameters are optional. For more information about these parameters, and how and when to start Control‑O, see Recommended Organization Method.

If you do not plan to use Control‑O to automate the IPL process, Control‑O can still be started during IPL, after JES has been brought up, by adding the following command to member COMMNDnn in the SYS1.PARMLIB library:

S CONTROLO

It is also possible to manually issue the above mentioned operator commands.

CMEM users:

If Control‑M is installed, Control‑O assumes responsibility for the functions of the CMEM facility. Therefore, it is important to verify that the CMEM monitor (CTMCMEM) is down before the Control‑O procedure is started.

For sites with CMEM rules that are to be implemented (triggered) in the early stages of the IPL process, command member COMMNDnn in SYS1.PARMLIB must contain the following command:

S CONTROLO,SUB=MSTR,OUTLIST=DUMMY[,ORDER=IPLRULES][,CMORDER=IOACMEML][,TYPE=IPL]

For more information about the parameters in the above statement, and how and when to start Control‑O, see Recommended Organization Method .

Shutting Down Control-O

It is usually not necessary to shut down Control‑O. However, if shutting down Control‑O becomes necessary, it is recommended that the active Control‑O monitor be replaced by starting a new Control‑O monitor, as explained in Replacing an Active Control-O Monitor

It is possible to shut down Control‑O with operator command F CONTROLO,STOP or P CONTROLO, but this is not recommended. Use an operator command to shut down Control‑O only if a problem cannot be resolved by the replacement method. If operator command F CONTROLO,STOP or P CONTROLO is used, Control‑O shuts down after a few seconds.

For CMEM users:

When Control‑O is shut down, the CMEM facility is also shut down. To restart Control‑O CMEM support after Control‑O has been completely shut down, issue the following operator command:

S CONTROLO,TYPE=CTOCMEM

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 ControlO is started, the user must tell ControlO which rule list to load. ControlO also loads the Global AutoEdit variable pools.

• When the user starts ControlO while ControlO is already active, the new ControlO inherits the rules and Global AutoEdit variables that were in use by the previous ControlO. It also inherits the subsystem and extended MCS consoles that the first ControlO 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 ControlO session when one ControlO 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 ControlO monitor automatically attempts to recover. It tries to replace the old monitor with a new one, without stopping its activity. ControlO performs this process only one time. If another error occurs, ControlO is then terminated.

2. If starting ControlO 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 ControlO with a new one, so the monitor is a normal started task with SYSOUTs.

3. To apply maintenance or a specific PTF to the ControlO 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.

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

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

   • Storage fragmentation may occur in the ControlO address space.

   • The JOBLOG and SYSPRINT may become lengthy and difficult to follow.

   • This process is known as swapping ControlO monitors.

• Storage in ECSA, allocated by the first ControlO, is used by the new ControlO. 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

Replacing the Active Control-O Executor Modules

When the active Control‑O monitor is replaced, most Control‑O modules are automatically reloaded. If maintenance is supplied for Control‑O executors modules or the messages they use, a reload command can be use to replace the modules without stopping Control‑O.

The following modules can be refreshed:

• CTOWTO, the ControlO executor module

• CTOAIDT, the CMEM executor module

• CTOJFRQ, the ControlO IEFJFRQ exit for JES2 command suppression and ONSYSOUT functionality

• messages used by these modules

F CONTROLO,RELOAD=CTOWTO

F CONTROLO,RELOAD=MESSAGES

Replacing the Active UNIX for z/OS (OpenEdition) Interface Module (CTOAODT)

When the active Control‑O Monitor is replaced, most Control‑O modules are automatically reloaded. If maintenance is supplied for the UNIX for z/OS (OpenEdition) interface module (CTOAODT), this module must be reloaded separately.

CTOAODT is shared among different IOA environments that are active in the system. Therefore, to replace the module, the current CTOAODT copy must be deactivated in all IOA environments on the system before a new copy can be loaded.

Deactivating the Current Copy of CTOAODT

To deactivate the current CTOAODT copy in all IOA environments on the system, do the following:

1. Stop Unix for z/OS (OpenEdition) support by issuing the following operator command for the ControlO Monitor of every IOA environment on the system:

   Copy

   F monitor,STOPOE

2. Alternatively, stop the appropriate monitor.

3. Wait for either of the following messages to appear:

   Copy

   CME792I OPENEDITION INTERFACE MODULE REMOVED
   
   CTO792I OPENEDITION INTERFACE MODULE REMOVED

   After the CME7921 message or the CTO7921 message has been displayed, Unix for OS/390 (OpenEdition) has been stopped, and the new copy of CTOADT can be loaded.

Loading the New Copy of CTOAODT

The procedure for loading the new CTOAODT copy in all IOA environments on the system is shown in the following steps:

1. Load the new module with the following operator command for the ControlO Monitor of the environment in which the PTF was applied:

   Copy

   F CONTROLO,STARTOE

2. Verify that the following message appears:

   Copy

   CTO781I OPENEDITION INTERFACE MODULE SUCCESSFULLY LOADED

3. Restore the OpenEdition support in the rest of the IOA environments where it was previously stopped, by running the following operator command for the ControlO Monitor of each one of them:

   Copy

   F monitor,STARTOE

4. Alternatively, restart the appropriate monitor if it was stopped.

Automatic Restart Management (ARM) and CMEM

The Control-O monitor should not be defined for Automatic Restart Management (ARM) because

• Control-O has its own recovery process

• since Control-O is active on each system, there is no need to move it to another system when the original system becomes inactive.

Control-O Rules

Rule Types

In Control‑O there are two types of rules

• ControlO rules that are created using the ControlO Rule Definition screen (option OR in the IOA Primary Option menu)

• CMEM rules that were are using the CMEM Rule Definition screen (option C in the IOA Primary Option menu) for triggering external events in ControlM

• CMEM rules can contain only the following types of statements:

  • ON JOBARRIV

  • ON JOBEND

  • ON DSNEVENT

  • ON STEP

  • DO FORCEJOB

  • DO COND

  • DO RESOURCE

  • DO STOPJOB

  CMEM rules can also contain DO SHOUT and DO RULE statements if ControlO is installed. CMEM tables cannot contain ControlO rules (that is, rules that contain statements other than the types listed above). The type of table (ControlO vs. CMEM) is determined by the way in which the table is loaded.

• CMEM rules are

  • loaded from DD statement DACTMLST

  • ordered or forced from the CMEM Rule Definition screen (Screen C)

  • loaded using modify command F CONTROLO,C=LIB(table)

• ControlO rules are:

  • loaded from DD statement DARULLST

  • loaded using modify command F CONTROLO,O|F=LIB(table)

  • ordered or forced from the ControlO Rule Definition screen (Screen OR)

  If a rule is rejected because it is not compatible with the method used to load it, the following message is issued to the SYSPRINT SYSOUT of the ControlO monitor:

  Copy

  LDT54DE RULE TYPE IS INCORRECT. TABLE table LIBRARY library

  When Control‑O loads a table, it only replaces tables of the same type. To change the type of a table, the table must be deleted and loaded again.If table A is loaded as a CMEM table, it cannot be reloaded as a Control‑O table. To load table A as a Control‑O table, first delete table A by issuing operator command

  Copy

  F CONTROLO,D=LIB(A)

  For more information, see Rule Loading Errors.

Loading Rules

Control‑O loads rules into ECSA only in the following situations:

• The ControlO instance is the first instance of ControlO started up in the IOA environment.

• The operator issues one of the following ControlO modify commands: F, O, or C.

The rule list is the list of rule tables loaded by Control‑O during startup. The DD statements DACTMLST and DARULLST point to the rule list. To load all rules in the rule list only, issue one of the following Control-O modify commands:

F controlo,O=ALL,REBUILD
F controlo,F=ALL,REBUILD

where controlo is the name of the Control‑O monitor.

A user orders or forces the Control‑O rules table from the Table list of the Rule Definition facility (screen OR), or from the CMEM Rule Definition facility (screen C).

During the load process, the monitor performs logical checks to verify the correctness of the rule.

In case of an error, the rule is rejected and an error message is sent to the IOA Log and the Control-O monitor DD statement SYSPRINT.

Ordering Rules

After the rules are loaded in ECSA, Control‑O orders them to facilitate proper triggering order, as follows:

By priority, from higher value to lower value

Within the same priority, in the order specified within the rule list

By rules that have no priority assigned

Illustration of Rule Order

The following example illustrates how rules are organized for triggering.

• Table A contains the following rules:

  • A1, with priority 10

  • A2, with no priority

  • A3, with no priority

• Table B contains the following rules:

  • B1, with priority 10

  • B2, with no priority

  • B3, with priority 100

• Table C contains the following rules:

  • C1, with priority 10

  • C2, with no priority

  • C3, with no priority

The rules are triggered in the following order:

B3, A1, B1, C1, A2, B2, C2, C3

Illustration of Rule Order After Loading a New Table

If you a load a new table in ESCA (that is, one that is not included in the current rule list), the previous triggering order of the existing rules is maintained, and the new rules are added to the end of the appropriate priority level.

The following example illustrates how loading a new table affects the triggering order. A new table, D, is loaded after the tables in Illustration of Rule Order on page were loaded. Table D contains the following rules:

• D1, with priority 10

• D2, with no priority

The rules are now triggered as follows:

B3, A1, B1, C1, D1, A2, B2, C2, C3, D2

Illustration of Rule Order After Reloading a Table

If you reload a table, the reloaded table replaces the original version of that table and the rules are replaced without affecting the previous priority and triggering order of the existing rules.

The following example illustrates the affect of reloading a table on the triggering order of the rules in the rule list. Table B is reloaded after Table D was loaded in Illustration of Rule Order After Loading a New Table.

The rules are now triggered as follows:

B3, A1, B1, C1, D1, A2, B2, C2, C3, D2

Note that this is the same order as before the table was reloaded.

Viewing the Rule Order

To view the rules by their load order, use screen 'OS', Control-O RULE STATUS in regular mode. To view the rules as shown by their priority order, enter the SORT primary command.

ON RULE rules are loaded at the bottom of the list. They are organized in the same order but the search is in the opposite direction, from lower to higher priority.

Automatic Loading of Rules

When Control‑O is started, and it is not replacing an active Control‑O monitor, it attempts to read a rule list from the member referenced by DD statement DARULLST. These are the rule tables to be automatically loaded by Control‑O. The name of the member can be passed in the Control‑O procedure parameter ORDER. The supplied default member, RULELIST, is in the Control‑O PARM library. Each line in the list has the following format:

date library table {FORCE|NOFORCE|ORDER}

Table 179 Format of Lines in Rule Table Member

For every line in the list, Control‑O loads the specified rule table from the specified library.

If either NOFORCE or ORDER is specified, each rule’s Basic Scheduling parameters are compared to the specified date, or to the current Control‑O working date if * is specified. If the rule must be scheduled on that date, it is loaded by Control‑O and activated.

If FORCE or no option is specified, each rule is loaded by Control‑O and activated. Use this option when you do not want to use Control‑O scheduling options.

Manual Loading of Rules

Member RULELIST contains a list of basic rule tables to be activated by Control‑O as it is started. To load additional tables, or to replace a currently active table with a new (updated) copy of the rules in the table, use one of the options described in this topic.

Option 1

Enter the Control‑O Online facility and use the ORDER or FORCE option in the Table List screen (Screen OR).

Option 2

Issue operator command

F CONTROLO,{O|F}=library(table)[,D=date]

Table 180 Fields for Manual Loading of Rules

F CONTROLO,F=CTO.PROD.RULES(CICSPROD)

F CONTROLO,F=CTO.PROD.RULES(*)

F CONTROLO,F=CTO.PROD.RULES(PROD*)

F CONTROLO, O|F=ALL [,REBUILD]

F CONTROLO,F=CTO.PROD.RULES(?CICS*)

Manual Loading of CMEM Rules

The member referenced by DD statement DACTMLST during startup contains a list of CMEM rule tables to be automatically ordered by Control‑O when it is started.

To load additional tables, or to replace a currently active table with a new (updated) copy, use one of the options described in this topic.

Option 1

Enter the CMEM Online facility (=C), and use the FORCE option in the Table List screen.

Option 2

Issue operator command

F CONTROLO,C=library(table)

Table 181 Fields for Manual Loading of CMEM Rules

F CONTROLO,C=CTM.CMEM.RULES(DATASET)

F CONTROLO,C=CTM.CMEM.RULES(*)

F CONTROLO,C=CTM.CMEM.RULES(BKP*)

F CONTROLO,C=CTM.CMEM.RULES(?CICS*)

F CONTROLO,O|F=ALL[,REBUILD]

Deleting (Deactivating) an Active Rule Table

To deactivate an active rule table, use an operator command such as

F CONTROLO,D=CTO.PROD.RULES(CICSPROD)

A single rule can also be deleted or held using appropriate line commands in the Rule Status screen.

Rule Loading Errors

When loading CMEM or Control‑O rule tables, error message LDT54DE is issued when

• loading a CMEM table that contains one or more ControlO rules

• loading a CMEM table as a ControlO rule table

• loading a ControlO rule table as a CMEM table

These errors and the corrective action that must be taken are described in more detail below. If one of these errors occurs, the specified table is rejected and the following error message is issued to the SYSPRINT SYSOUT of the Control‑O monitor:

LDT54DE RULE TYPE IS INCORRECT. TABLE tablname LIBRARY libname

Table 182 Fields in Error Message LDT54DE

Loading a CMEM table that contains one or more Control-O rules

CMEM tables can only have rules that contain the following types of statements: ON JOBARRIV, ON JOBEND, ON DSNEVENT, ON STEP, DO FORCEJOB, DO COND, DO RESOURCE, and DO STOPJOB. If Control‑O is installed, CMEM tables can also have rules that contain DO SHOUT and DO RULE statements.

If a user loads a CMEM table that has a rule that contains an invalid statement type, an error occurs. To resolve the error, the user must do one of the following:

• Remove the invalid rule from the CMEM table and reload the CMEM table

• Delete the table from ControlO, then reload the table as a ControlO rule table using the ControlO Rule Definition screen (option OR on the IOA Primary Option menu), or using modify command

  Copy

  FCONTROLO,O|F=LIB(table)

Loading a CMEM table as a Control-O rule table

• CMEM tables are created using the CMEM Rule Definition screen (option C in the IOA Primary Option menu). When they are loaded into ControlO, they are identified as CMEM tables.

• To load the rules in a CMEM table as a ControlO rule table, delete the CMEM table from ControlO and reload the table as a ControlO rule table.

Loading a Control-O rule table as a CMEM table

• ControlO rule tables are created using the ControlO Rule Definition screen (option OR in the IOA Primary Option menu). When they are loaded into ControlO, they are identified as ControlO rule tables.

• If a ControlO rule table contains only statements that are valid as CMEM rules, that table can be loaded as a CMEM table by deleting the ControlO rule table from ControlO and reloading the table as a CMEM table.

Reloading Rule Tables

Reloading a CMEM table as a Control-O rule table:

1. Delete the CMEM table from ControlO.

2. Reload the rule table from the library using the Control-O Rule Definition screen (option OR in the IOA Primary Option menu) or using modify command

   Copy

   F CONTROLO,O|F=LIB(table)

Reloading a Control-O rule table as a CMEM table:

1. Delete the table from ControlO.

2. Reload the rule table from the library using the CMEM Rule Definition screen (option C in the IOA Primary Option menu) or using modify command:

   Copy

   F CONTROLO,C=LIB(table)

Private REGION Requirements of the Control-O Monitor

Control‑O monitor procedure CONTROLO is supplied with a default region size of 5 MB. The region size can optionally be increased to a maximum of 2 GB.

Calculating Region Size

You must include the following items in your calculation of the amount of virtual storage needed by the Control‑O monitor:

• block size of the IOA Conditions file (fixed at 32,760)

The storage chunks allocated for this requirement are above the 16 MB line.

• number of records in the Message Statistics file, specified in parameter STREC# in member CTOPARM

• the monitor that loads the used records of the Message Statistics file into virtual storage

  Each entry of the Message Statistics file requires 100 bytes. For example, if there are 5000 entries in the Message Statistics file, the ControlO monitor needs a maximum of 500K of virtual storage to load the necessary records. The storage chunks allocated for this requirement are above the 16MB line.

• ControlO monitor working buffers, which require approximately 65000K of virtual storage

The storage chunks allocated for this requirement are mostly above the 16 MB line.

• ControlO monitor software, which requires approximately 2000K of virtual storage, depending on the environment and the functions used

  • The storage chunks allocated for this requirement are both above and below the 16MB line.

  • Sitedefined work areas and programs (for example, user exits). These items usually require a small amount of virtual storage. Therefore, it is usually not necessary to calculate the requirements of sitedefined components precisely. However, it is important that you allow some extra storage space for these components. The storage chunks allocated for this requirement are both above and below the 16MB line.

Troubleshooting

MVS allocates the region size specified for the Control‑O monitor unless a local exit (for example, IEALIMIT, IEFUSI, or another MVS or JES exit) is used to limit the region size of jobs and/or started tasks at the site.

Message IEF374I in the third SYSOUT of the Control‑O monitor indicates the amount of virtual storage used by the Control‑O monitor. Compare the information in this message with the existing region size definition.

• If sufficient virtual storage is not available for the ControlO monitor, use on-site performance tools to determine if the specified region size was rejected by MVS (for example, using a local exit).

• If MVS accepted the specified region, recalculate the ControlO monitor’s virtual storage requirements, as shown above, and modify the region size in the EXEC statement of the ControlO monitor procedure accordingly.

• If an MVS procedure rejected the specified region size, contact your system administrator.

Storage Allocation

At startup, the Control‑O monitor allocates working storage. Control‑O can allocate most virtual storage above the 16 MB line. The decision as to whether to allocate above or below the 16 MB line is made by MVS, which considers the specified job, the amount of requested storage, MVS exits, and so on.

Structure of the IOA Conditions File

For information about the structure and space requirements of the IOA Conditions file, see the section that discusses the structure of the IOA Conditions File in the INCONTROL for z/OS Installation Guide: Installing.

Control-O Usage of the Common Service Area (CSA and ECSA)

Control‑O receives control for processing events under the various tasks in the system, that is, Control‑O acts as part of the address space that issued the corresponding message, command, or other event. For that reason, some of the code and data that are in use by Control‑O reside in common storage, accessible from all address spaces, as outlined below. Most of this common storage is above the 16MB line, in the ECSA, but a small portion is allocated by Control‑O below the 16MB line, in the CSA, due to MVS services requirements.

Use the information in ECSA Usage (Above the 16 MB Line) and CSA Usage (Below the 16 MB Line) to calculate Control‑O ECSA and CSA storage requirements.

ECSA Usage (Above the 16 MB Line)

The table describes the Control‑O components that use ECSA.

Table 185 ECSA Usage (Above the 16 MB Line)

CSA Usage (Below the 16 MB Line)

The table describes the Control‑O components that use CSA.

Table 186 CSA Usage (Below the 16 MB Line)

Control-O Usage of the Extended Link Pack Area

If you install ON SMS support, which implies the execution of a job that copies supporting programs for BMC libraries to the SYS1.LPALIB library, you have to allow for Extended Link Pack Area (ELPA) storage.

ELPA Usage

Table 187 ELPA Usage

Recommended Organization Method

The primary function of Control‑O is to automate events and console operation. An especially important use of Control‑O is the automation of system startup (IPL).

The following topics describe the recommended Control‑O organization method for automating the IPL process. If you do not automate the IPL process, Control‑O organization is simplified, because certain MVS‑related restrictions need not be addressed. In this case, skip directly to Rule Scheduling.

System Definitions

The IOA subsystem name, as defined in IOA Installation parameter SUBSYS, must be the first subsystem name after the primary subsystem in the subsystem list (member IEFSSNnn in SYS1.PARMLIB). This enables Control‑O to control commands directed to other MVS subsystems before they are executed by these subsystems. However, to control JES commands before they are executed by JES, Control‑O uses JES exits or an additional subsystem name, defined optionally in the Control‑O installation parameters. For more information, see the JCMDSSN parameter in the Control‑O chapter of the INCONTROL for z/OS Installation Guide: Installing.

When using the keyword parameter form, add a record to member IEFSSNnn in the following format:

SUBSYS SUBNAME(xxxx)

where xxxx is the name of the subsystem specified in IOA installation parameter SSNAME.

For more information, see the IBM manual MVS Initialization and Tuning Reference.

The Control-O monitor must be started at an early stage of IPL. To do this, its procedure and included members should reside in a PROCLIB library specified in member MSTJCLxx in the IEFPDSI DD statement, and a START command should be added to member COMMNDnn in the SYS1.PARMLIB library. To achieve this, do the following:

1. Make sure the IOA environment was installed using the IEFJOBS DD statement.

2. CTOTROLO, IOASETxx, and IOAENVxx procedures must reside in SYS1.PROCLIB or another PROCLIB specified in the MSTJCLxx member in the IEFPDSI DD statement.

3. The JCLLIB from the CTOTROLO procedure in the IOA PROCJCL library referenced by the IEFJOBS DD statement in the MSTJCLxx member should be removed (or commented out).

4. Member COMMNDnn in the SYS1.PARMLIB library (where nn is either the number specified in member IEASYS in the same library, or 00) must contain the following command as one of the first commands in the member:

   Copy

   COM='S CONTROLO,SUB=MSTR,TYPE=IPL,ORDER=IPLRULES,OUTLIST=DUMMY’

The following Control‑O and IOA files are allocated to the Control‑O monitor:

• IOA LOAD library

• IOA Global Variables library (dynamically allocated)

• IOA Conditions file

• Calendar library

• PARM library

• Message Statistics file (dynamically allocated)

• Rules library (dynamically allocated)

• Automation Log file (dynamically allocated)

Because Control‑O is started as part of IPL, you must either catalog all these files in the MVS Master Catalog, or specify the VOLSER and UNIT parameters for each of the files. The dynamically allocated files (for example, the Message Statistics file) must be in the Master catalog.

If you specified parameters VOLSER and UNIT for these files and you move the files to another disk, you must modify the Control‑O procedure as well.

Ensure that a correct value is specified for the JESTYPE IOAPARM parameter. Do not leave it blank.

It is recommended that Control‑O start and control the initialization of other system components (JES, VTAM, TSO, and so on).

The on-site enqueue manager must be up before any attempt is made by Control‑O to update any IOA file. For more information, see the QNAME parameter in the IOA chapter, and the CTOQNAM parameter in the Control‑O chapter, of the INCONTROL for z/OS Installation Guide: Installing.

Use of Two Rule List Members

The ORDER parameter of the Control‑O monitor specifies the name of a member containing the list of rules to be loaded by Control‑O upon startup. The easiest organization method is using one list member containing all Control‑O tables (for example, the supplied member RULELIST). This is the preferred method when Control‑O does not control IPL. However, if Control‑O controls IPL, it must be organized somewhat differently.

As your site’s use of Control‑O expands, it is possible that hundreds of operations rules are defined. Loading all of these operation rules can take time. Control‑O does not start to analyze messages until it has finished loading all rules in the initialization rule list. Consequently, if the list is quite large, Control‑O may not detect some of the messages and commands issued during the beginning of the IPL process.

To ensure analysis of all messages, it is recommended to place all rules that control the IPL process in a separate list. This list is loaded when Control‑O is started by overriding the default list member name using parameter ORDER to designate member IPLRULES. Member IPLRULES must contain only the rule tables to be used during IPL. One of the rules in this member must load the remaining Control‑O rule tables.

Multiple Rule Table Lists for CMEM Rules

Parameter CMORDER specifies the name of the member that contains the CMEM list (that is, the list of CMEM rule tables to be loaded by Control‑O upon startup). It is usually recommended that you list all CMEM rule tables in one list. The default name for the member containing this list is IOACMEML. However, it is sometimes recommended that you list certain rule tables separately.

Control‑O does not start to analyze CMEM events until it has finished loading all rule tables in the CMEM list specified using parameter CMORDER. If a large number of rules have been defined at your site, Control‑O may not detect some CMEM events during the beginning of the IPL process.

To ensure detection of all CMEM events, it is recommended that you place CMEM rules to be triggered during the IPL process in a separate list in member IOAIPLCM, and that you specify this list using parameter CMORDER. Rule tables specified in this way are loaded and activated during the startup process.

Replacing the IPL Control-O

Operation of Control‑O involves processing phases that are implemented by starting separate Control‑O monitors, each one replacing the previous one.

Table 188 Phases for Replacing the IPL Control-O

Parameter TYPE of operator command START CONTROLO enables you to specify the Control‑O processing phase for a specific monitor. The following table lists the valid values for this parameter:

Table 189 Values for Parameter TYPE

The Control‑O TYPE is displayed in the following initialization message:

CTO147I    Control‑O INITIALIZATION COMPLETE,TYPE=type,SUB=job‑entry‑subsystem

This message can be used by Control‑O rules whenever phase‑dependent processes are handled.

CMEM Users:
This note also applies to CMEM rules loaded from DD statement DACTMLST.

Rule Scheduling

Control‑O is usually started at an early stage of IPL and remains active until shutdown. Most rules behave the same on any date. However, it is sometimes necessary to schedule different rules for different dates. For example, you may want to trigger one response to a certain message on a regular working date and a different response to the same message on the first day of a month.

Under Control‑O, you can define scheduling parameters for rules. For example, a rule can be scheduled for a specific date only. The scheduling criteria of rules are checked when a rule is ordered (either automatically or manually).

If a rule is subject to scheduling criteria, these criteria must be checked daily, and the rule loaded and activated only if it must be scheduled according to its scheduling criteria. You should reload rules on a daily basis using a time‑initiated command (rule) that issues the following order command for all Control‑O tables at a specified time of day:

F CONTROLO,O=ALL,REBUILD

Displaying Active Rules

The Rule Status screen displays a list of all rules that have been ordered and their statuses. The displayed rules can be held or deleted or freed. Alternatively, enter operator command:

F CONTROLO,DISPLAY[=DETAIL]

The optional DETAIL parameter enables you to generate a detailed list, with more extensive information than a regular list.

The list is sent to the console.

A regular list of Control-O rules includes the following information:

Table 189a Information in a Regular List of Rules

The following example shows the format of a detailed list of Control-O rules with one ON DSNEVENT rule:

CTO12SI RULE LIST DISPLAY FOR LPAR MVS3:                      
                                                              
NAME TYPE STATUS OWNER LAST-ORDERED   ACTIVE# LAST-TRIGGERED  
  TABLE    SEQNO LIBRARY                            PRIORITY  
  IN ADDITIONAL-FILTERS                                  ON#  
------------------------------------------------------------  
FTP* D    ACTIVE K81   20230301 19:45 000001  20230302 13:10  
  K81ONDSN 00002 IOAA.DEV#R3.CTO.OPR.RULES              (  )  
  N FTP*  INCOMING.DATA.SET                      C        01  

A detailed list of Control-O rules includes the following information:

Table 189b Information in a Detailed List of Rules

Table 189c Additional Filters in a Detailed List of Rules

Management of Control-O Facilities

This section contains descriptions of commands and considerations for managing various Control‑O facilities and components. The following topics are discussed:

• Controlling the Message Statistics Facility

• Controlling the Automation Log Facility

• Writing to the IOA Log Facility

• Management of the Control-O Status Monitoring System (COSMOS)

• Controlling Rule Operation Mode

• Specifying Actions to Be Performed on a Control-O Server

• Controlling z/OS UNIX System Services (USS/OpenEdition) Support

• Accessing AutoEdit Variables Globally

• Modifying the Control-O Sleeping Interval

• Refreshing the Control-O Security Cache

• Problem Determination

Controlling the Message Statistics Facility

The Message Statistics facility allows accumulation and display of statistics for the messages or commands issued by the system on which Control‑O is active.

The Message Statistics facility counts messages and commands by message or command ID. Each time a message or command is displayed, the counter for the corresponding entry in the Statistics file is incremented. When a new message ID or %%$STATID value is detected, a new entry is opened in the Statistics file.

Statistics accumulation is normally started automatically when Control‑O is brought up. However, when necessary, accumulation of statistics can be controlled by the following operator commands:

• Stop statistics accumulation

  Copy

  F CONTROLO,STOPSTAT

  This command can be used if statistical accumulation is no longer required or if it becomes necessary to reformat the Statistics file without bringing down ControlO.

• Start statistics accumulation

  Copy

  F CONTROLO,STARTSTAT

• Reset statistics for all messages and commands

  Copy

  F CONTROLO,RESETSTAT

Preventing Unnecessary Enlargement of Statistics Files

The Message Statistics facility counts messages and commands by message or command ID. The first word of the message or command is the message or command ID.

To prevent the Statistics files from becoming too large and to eliminate duplicate information, it may be appropriate to group messages or commands according to other criteria. It is useful, for example, to group messages or commands under one message or command ID when:

Messages start with free text. Accumulating each of these messages under a different message ID enlarges the size of the Statistics file, and may prevent the accumulation of meaningful statistics for the message.

Concatenation of JES2 commands with different operands results in separate statistics accumulation for each operand. For example, statistics for $PJ05555 and $PJ01234 are normally accumulated under different IDs even though both IDs refer to the same command.

Separate statistics are accumulated for messages that are not of interest to the user.

AutoEdit reserved variable %%$STATID can be used to specify the ID under which the messages or commands are accumulated. For example

ON COMMAND $P*
DO SET %%$STATID=$P

Rule table STATS from the RULES library has been provided to perform the necessary grouping by %%$STATID. This table can be adapted and used according to site requirements.

Handling Near-Full and Full Conditions for the Statistics File

When the Statistics file becomes more than 90% full, Control‑O issues unrollable message CTO240W as a warning.

When Control‑O detects that the Statistics file is full, it issues unrollable message CTO241E. Control‑O then stops tracking statistics for new messages but continues to update the counters of messages already in the Statistics file.

If message CTO240W or CTO241E is issued, it is recommended that the operator enlarge the Statistics file using utility CTOCSF and check if messages can be grouped by %%$STATID.

Controlling the Automation Log Facility

The Automation Log facility allows accumulation and display of automation information from all inputs available to Control‑O.

The Automation Log facility is started automatically when parameter AUTOMLOG in member CTOPARM is set to V or D. For more information, see the Control‑O chapter in the INCONTROL for z/OS Installation Guide: Installing.

While Control‑O is active, the Automation Log facility is controlled by the following operator commands:

• Stop Automation Log accumulation

  Copy

  F CONTROLO,AUTOLOG=NO

  This command can be used when the Automation Log is no longer required or when it becomes necessary to reformat or rebuild the Automation Log file without bringing down ControlO. Message CTO297I indicates that Automation Log accumulation has stopped.

  The Automation Log can be viewed using Screen OL, even when ControlO is inactive or Automation Log accumulation has been stopped.

• Start Automation Log accumulation

  Copy

  F CONTROLO,AUTOLOG=YES

  Message CTO297I indicates that Automation Log accumulation has started.

Determining the Size of the Log

The Automation Log is a wraparound dataset, which means that the number of records in the file is constant and, when the file is full, a new record overwrites the oldest record. Automation Log entries can be archived or backed up for subsequent retrieval using utility CTOALOCP. For more information, see the INCONTROL for z/OS Utilities Guide.

If backup is performed on a regular basis, the Automation Log must be large enough to prevent overwriting record that have not been backed up. The size of the Automation Log is specified in installation parameter ALREC#. The backup frequency depends on site requirements.

Preventing Logging of Unnecessary Messages

Some messages may be unnecessary for a particular task. Use the System AutoEdit variable %%$AUTOLOG to control which messages are entered into the Automation Log. The table lists the valid values.

Table 190 Values for AutoEdit Variable %%$AUTOLOG

Prevent messages whose ID starts with TST from being written to the Automation Log.

ON MESSAGE TST*
DO SET %%$AUTOLOG=N

Writing to the IOA Log Facility

Installation parameter SMODE (Stand-alone mode) in member CTOPARM determines how requests to write to the IOA Log facility are handled. The following operator command can be used to temporarily override the value specified in this installation parameter:

F CONTROLO,SMODE=x

where x equals F (Forced), Y (Yes), or N (No).

For a description of SMODE values, see the ICE Step 2.1 discussion of Control‑O Operational Parameters, in the Control‑O chapter of the INCONTROL for z/OS Installation Guide: Installing. If an invalid value is specified for SMODE=, the following message is generated:

MTO367E        SMODE VALID VALUES ARE F, Y, AND N   

Management of the Control-O Status Monitoring System (COSMOS)

The Control‑O Status Monitoring System (COSMOS) is used to monitor the status of objects in the computing environment. When activated, COSMOS ensures that specified objects are maintained in their specified desired status.

Normally, COSMOS must be activated as part of the Control‑O startup process.

While Control‑O is active, the commands listed in the table can be used to control COSMOS operations.

Table 191 Commands for Controlling COSMOS Operations

For more information about these and other COSMOS commands, see the online facilities chapter in the Control‑O/COSMOS User Guide.

Controlling Rule Operation Mode

The mode of operation (that is, the trace mode) for a rule is determined by parameter MODE in its rule definition. Sometimes it is useful to override the operation mode of all active rules and verify that events and actions are recorded in a particular way. For example

Ensure a full trace of all rules (that is, all events and actions are recorded) to facilitate analysis of the interaction between rules.

Record (trace) only the triggering of every rule.

Global trace operations are requested using the following operator commands:

• Activate a full trace

  Copy

  F CONTROLO,LOG=TRIGGER

  All rules are fully traced as if they were defined with mode LOG. This operator command must only be used temporarily for specific tests, because extended use of full trace mode can adversely affect ControlO performance.

  Trace rule triggering only

  Only rule triggering is traced for all rules. However, rules defined with mode LOG are fully recorded.

  Copy

  F CONTROLO,LOG=ALL

• Restore the default operation mode (as defined in the rule definition) for each rule

  Copy

  F CONTROLO,LOG=DEFAULT

Specifying Actions to Be Performed on a Control-O Server

MODIFY commands to Control-O can be used to specify the action to be performed on a server. These actions can also be performed by the SERVERS option in the Automation Options screen (Screen OA).

The format of the command to modify servers is

F CONTROLO,SERVER=serverid,action

In this command,

• serverid is the ID of the server to be modified. The value ALL can be specified to apply the action to all the servers.

• action is one of the actions described in Table191a.

Table 191a MODIFY Command Actions to Be Performed on a Server

Controlling z/OS UNIX System Services (USS/OpenEdition) Support

z/OS has introduced major changes and enhancements to the UNIX for z/OS (OpenEdition) environment to make it part of the MVS core. Consequently, certain applications, such as IBM FTP, were converted to use the USS (Unix Services for z/OS). As a result, IBM FTP stopped issuing allocation and deallocation messages to the JESYSMSG spool dataset.

Control-O provides a special interface to support dataset-triggering events originating from UNIX.

The Unix for z/OS interface is shared by all Control-O installations in the LPAR and is version-independent. The first Control-O subsystem to initialize loads the Unix for z/OS interface module to common storage. This interface is later used by all other Control-O subsystems. Upon startup, every Control-O subsystem registers itself with the Unix for z/OS interface. This registration mechanism enables the Unix for z/OS interface to recognize all the available Control-O subsystems and to call them when a new process is created by a fork/spawn request and associated with a BPXAS initiator (for example, when a new ftp session has started). The Control-O monitors are called one by one in the order that they registered with the interface. The first Control-O subsystem to have a matching rule for this address space will monitor it for z/OS dataset-triggering events.

When a Control‑O subsystem shuts down, it removes itself from the Unix for z/OS interface. The last Control‑O subsystem to shut down removes the Unix for z/OS interface from common storage.

The following sequences of messages indicate that the Unix for z/OS interface was successfully installed:

• for the first ControlO subsystem to initialize

  Copy

  CTO820I INITIALIZATION OF OPENEDITION SUPPORT STARTED
  CTO821I OPENEDITION INTERFACE MODULE SUCCESSFULLY LOADED
  CTO822I SUBSYSTEM REGISTERED WITH OPENEDITION INTERFACE
  CTO823I INITIALIZATION OF OPENEDITION SUPPORT ENDED SUCCESSFULLY

• for any subsequent ControlO subsystem

  Copy

  CTO820I INITIALIZATION OF OPENEDITION SUPPORT STARTED
  CTO822I SUBSYSTEM REGISTERED WITH OPENEDITION INTERFACE
  CTO823I INITIALIZATION OF OPENEDITION SUPPORT ENDED SUCCESSFULLY

The following sequences of messages indicate that the Unix for z/OS interface was successfully deactivated:

• for any ControlO subsystem except from the last subsystem to shut down

  Copy

  CTO830I DEACTIVATION OF OPENEDITION SUPPORT STARTED
  CTO831I SUBSYSTEM REMOVED FROM OPENEDITION INTERFACE
  CTO833I DEACTIVATION OF OPENEDITION SUPPORT ENDED SUCCESSFULLY

• for the last ControlO subsystem to shut down

  Copy

  CTO830I DEACTIVATION OF OPENEDITION SUPPORT STARTED
  CTO831I SUBSYSTEM REMOVED FROM OPENEDITION INTERFACE
  CTO832I OPENEDITION INTERFACE MODULE REMOVED
  CTO833I DEACTIVATION OF OPENEDITION SUPPORT ENDED SUCCESSFULLY

Control‑O enables the operator to start and stop the Unix for z/OS interface using the Modify operator command. Usually, there is no need to intervene with the default processing performed by Control‑O. The following operator commands are available:

F CONTROLO,STARTOE
F,CONTROLO,STOPOE[,FORCE]

The STARTOE command instructs a Control‑O subsystem to restart the Unix for z/OS interface. This includes initializing the interface (if no other subsystem has initialized it) and/or registering the current subsystem with the Unix for z/OS interface. If the STARTOE command is issued for a subsystem that is already registered with the Unix for z/OS interface, the following message is generated:

CTO828I SUBSYSTEM ALREADY REGISTERED WITH OPENEDITION INTERFACE

The STOPOE command instructs a Control‑O subsystem to deactivate the Unix for z/OS interface. This includes removing the current subsystem from the Unix for z/OS interface and removing the Unix for z/OS interface from common storage if no other subsystem is using it. If the STOPOE command is issued for a subsystem that is not registered with the Unix for z/OS interface, the following message is generated:

MTO836W SUBSYSTEM NOT REMOVED FROM OPENEDITION INTERFACE: SUBSYSTEM NOT FOUND

If the STOPOE command is issued when the Unix for z/OS interface is not installed, the following message is generated:

MTO835W OPENEDITION INTERFACE MODULE NOT INSTALLED

The STOPOE,FORCE command instructs Control‑O to remove the Unix for z/OS interface from common storage even if one or more Control‑O subsystems are still registered with it.

Control‑O also provides Started Procedure CTOOEDSC. This procedure can be started from the console using the START command. Procedure CTOOEDSC acts like a STOPOE,FORCE command and removes the Unix for z/OS interface regardless of any registered subsystems. The STOPOE,FORCE command and procedure CTOOEDSC must be used only in case of emergency.

Accessing AutoEdit Variables Globally

AutoEdit variables can be made available globally to Control‑O (and other INCONTROL products) in one of the following two methods:

• using global members

• using the IOA Variable Database facility

Global members and databases are managed in different ways.

When Control‑O is started, it reads the global members and IOA databases and loads the global variables defined in those members and databases into memory. The list of members and databases to be loaded is specified in DD statement DAGLBLST of the Control‑O monitor procedure.

The following topic describes file configuration for global members. For a description of file configuration for databases, see IOA Administration.

Global Members

Global members reside in global libraries. A different global library is used for each computer (SMF ID) on which Control‑O operates. The global library name is composed of

• the prefix defined for Control-O operations files in the OLPREFO ControlO target library parameter

• the global identifier .GLB

• the string "CPU" followed by the SMF ID of the specified computer

CTO.Vxxx.GLB.CPUSYSA

$GLOBAL is usually the default global member. This member contains Control‑O AutoEdit variables that are not assigned to specific global members, yet must be available globally. The member format is identical to the format of a Control‑M AutoEdit variable member. Therefore, Control‑O global members can be referenced by Control‑M jobs using MEMSYM and LIBSYM parameters.

Updates or additions to global variables (by rules or KOA scripts) are kept in memory by Control‑O and are available to all other rules. While Control‑O is active, global variables can be reloaded from, or written back to, the PDS (partitioned dataset) global library, in total or by member name, using operator commands LOADGLOBAL and WRITEGLOBAL. When Control‑O is stopped, the global variables are written back to their respective partitioned datasets.

Loading Global Variables

Use the following operator command to load global variables from a global member (or an IOA variable database) into Control‑O memory:

F CONTROLO,LOADGLOBAL[=memname]

where memname indicates the global members (or variable databases) to be loaded. The table lists the valid values.

Table 192 Values for Loading Global Variables

If no memname value is specified with a LOADGLOBAL command, only member $GLOBAL (that is, the default global member) is loaded.

WARNING: Issuing LOADGLOBAL is hazardous in a live system!

Changes to the databases (for example, through %%SET in JCL, DO SET, or SET VAR) are accumulated in memory and are written to disk during the next WRITEGLOBAL command (performed automatically for the IOAVAR database at set intervals). Between the changes and the WRITEGLOBAL command is a time window in which the LOADGLOBAL command will delete the changes. BMC recommends only using the LOADGLOBAL command for updating a database during a scheduled downtime.

Updating Global Variables

Use the following operator command to update global members (or databases) with the current status of the global variables in memory:

F CONTROLO,WRITEGLOBAL[=memname]

where memname indicates the global members (or databases) to be updated. The following table lists the valid values:

Table 193 Values for Updating Global Variables

If no memname value is specified with a WRITEGLOBAL command, only the $GLOBAL member (that is, the default global member) is updated.

Defining a New Global Member

Rules related to a specific application can use their own global member to isolate their variables from the rules of other applications, to enable the use of checkpoints or to perform initialization on an application basis.

To define a new global member, create a member in the GLB library and add its name to the global member list (DAGLBLST).

The global member list (DAGLBLST) is referenced by DD statement DAGLBLST of the Control‑O monitor procedure and usually resides in member DAGLBLST of the Control‑O PARM library. Each line of the global member list describes a global member (or database).

Format

member <attribute>

Table 194 Fields for Global Member List Lines

The following code contains sample content for the DAGLBLST member of the Control‑O PARM library:

Figure 68 Sample Content for Member DAGLBLST

$Command ===>                                                  Scroll ===> CSR
000001 ***********************************************************************
000002 *       ADD LIST OF POOLS                                              
000003 READONLY    INPUT      A READ-ONLY MEMBER                              
000004 * ******************************************************************** 
000005 * *         COSMOS RELATED POOLS                                     * 
000006 * ******************************************************************** 
000007 *                                                                      
000008 *           DEMO DATABASES                                             
000009 *                                                                      
000010 COSWORKV    TEMP       COSMOS - WORKING VARIABLES                      
000011 COSALLPR    DBINPUT    COSMOS - DEMO PREREQUISITES DATABASE            
000012 COSALLMT    DBINPUT    COSMOS - DEMO METHODS DATABASE                  
000013 COSSTCOB    S1TEMP     COSMOS - DEMO STC WORKING DATABASE              
000014 COSVTMOB    S1TEMP     COSMOS - DEMO VTAM WORKING DATABASE             
000015 COSIMGOB    DBTEMP     COSMOS - DEMO SYSIMAGE WORKING DATABASE         
000016 COSSTCSD    DBINPUT    COSMOS - DEMO STC SOURCE DATABASE               
000017 COSVTMSD    DBINPUT    COSMOS - DEMO VTAM SOURCE DATABASE              
000018 COSIMGSD    DBINOUT    COSMOS - DEMO SYSIMAGE SOURCE DATABASE          
000019 *                                                                      
000020 *           PROD DATABASES                                             
000021 *                                                                      
000022 * PRDALLPR  DBINPUT    COSMOS - PROD PREREQUISITES DATABASE            
000023 * PRDALLMT  DBINPUT    COSMOS - PROD METHODS DATABASE                  
000024 * PRDSTCOB  DBTEMP     COSMOS - PROD STC WORKING DATABASE              
000025 * PRDVTMOB  DBTEMP     COSMOS - PROD VTAM WORKING DATABASE             
000026 * PRDSTCSD  DBINPUT    COSMOS - PROD STC SOURCE DATABASE               
000027 * PRDVTMSD  DBINPUT    COSMOS - PROD VTAM SOURCE DATABASE              
000028 *                                                                      
000029 * ******************************************************************** 
000030 * *         COSMOS SAMPLE DEFINITION FOR SYSPLEX-WIDE MANAGEMENT     * 
000031 * ******************************************************************** 
000032 *                                                                      
000033 *           DEMO DATABASES                                             
000034 *                                                                      
000035 * COSSTCOB  S1TEMP     COSMOS - DEMO STC WORKING DATABASE FOR SYSPLEX  
000036 * COSVTMOB  S1TEMP     COSMOS - DEMO VTAM WORKING DATABASE FOR SYSPLEX 
000037 * ******************************************************************** 
000038 * *         TUTORIAL RELATED POOLS                                   * 
000039 * ******************************************************************** 
000040 TUTORIAL    DBINPUT   TUTORIAL                                         
000041 * ******************************************************************** 
000042 * *         XAE TEST RELATED POOLS                                   * 
000043 * ******************************************************************** 
000044 XAES1D01  S1TEMP    XESXAE - DEMO - S1 - TEMP                          
000045 * XAES1D02  S1INPUT   XESXAE - DEMO - S1 - INPUT                       
000046 * XAES1D03  S1PROT    XESXAE - DEMO - S1 - PROT (SAME AS DBPROT)       
000047 * XAES1D04  S1INOUT   XESXAE - DEMO - S1 - INOUT (SAME AS DBINOUT)     
000048 XAES2D01  S2TEMP    XESXAE - DEMO - S2 - TEMP                          
000049 XAES2D02  S2INPUT   XESXAE - DEMO - S2 - INPUT                         
000050 * XAES2D03  S2PROT    XESXAE - DEMO - S2 - PROT (SAME AS DBPROT)       
000051 * XAES2D04  S2INOUT   XESXAE - DEMO - S2 - INOUT                       

Once the new global member (or database) has been defined and listed, it must be activated with the following operator command:

F CONTROLO, LOADGLOBAL=member

where member is the name of global member (or database).

Automatic Compression of the Global Library

Because of its PDS (partitioned dataset) organization, the global library is prone to D37 abends (insufficient space to write to disk). If, at your site, there is no product to keep the library compressed, Control‑O enables you to automatically compress the global library whenever it becomes full, as explained below.

The Automatic Compression facility is normally activated when the global library is full (that is, when a D37 abend is encountered during a WRITEGLOBAL operation).

Before attempting to compress the global library, Control‑O backs up the library to a sequential file using utility IEBCOPY. The name of the backup sequential file is the name of the specified global library with the suffix ".COPY". For example, when global library CTO.Vxxx.GLB.CPUSYSA is backed up, the resulting sequential file name is: CTO.Vxxx.GLB.CPUSYSA.COPY

The backup sequential file is allocated only if parameter GLBCOMP in member CTOPARM is set to Y (Yes), indicating that the global compress feature is required.

The Automatic Compression facility uses member $$COMPST of the global library to track the progress of the compression operation. $$COMPST is a single record member that is created automatically when the global library is defined.

For each step in the backup and compression process, variable %%STATUS in member $$COMPST is updated to reflect the status of the compression process. The following table lists the possible values for this variable:

Table 195 Values for Variable $$COMPST

Whenever the global library is accessed (using a LOADGLOBAL or WRITEGLOBAL operation), the value of %%STATUS is checked to ensure that the library was not corrupted during the last automatic compress operation.

• If the value of %%STATUS is OK, the requested LOADGLOBAL or WRITEGLOBAL operation is performed.

• If the value of %%STATUS is S2, the Automatic Compression facility automatically restores the global library from the backup file and compresses it before execution of the LOADGLOBAL or WRITEGLOBAL operation.

• If the value of %%STATUS is S1, the global library and backup may be corrupt, and therefore the operation cannot be performed. An error message is issued.

Enabling Automatic Compression

If automatic compression of the global library was not enabled at time of installation, you can enable it by performing the following steps:

1. Bring down ControlO.

2. Specify Y (Yes) for parameter GLBCOMP in member CTOPARM of the IOA PARM library.

3. Submit job NEWGLOB in the IOA INSTWORK library. This job

   • renames the old global library

   • defines a new global library (using the old library name) and a sequential backup file (used by the Automatic Compression facility)

   • copies the contents of the renamed global library to the new global library

   A job can be tailored by using the ICE activity "Tailor Job" from the Housekeeping menu.

4. Restart ControlO.

Modifying the Control-O Sleeping Interval

Control‑O wakes up every few seconds and checks on time‑related events. This time interval is defined in Control‑O installation parameters and can be changed by the system administrator. In addition, the interval can be modified by operator command

F CONTROLO,INTERVAL=nn

where nn represents the interval in seconds.

If Control‑M is active at your site, it is recommended that you specify an interval shorter than the Control‑M sleeping interval.

It is recommended that the interval be modified by automatic commands that are invoked by the Control‑O monitor itself, according to set conditions and time ranges, and not manually by the operator.

The optimal sleeping interval depends on the processing power of the machine. Depending on the processing power of the machine, the sleeping interval should usually not be less than the number of seconds indicated in the following table:

Table 196 Sleeping Intervals per Machine

There is no practical benefit in setting the interval to less than the above minimum. Doing so can actually slow down the operation of Control‑O.

When the modification is accepted by Control‑O, the following message is displayed on the operator console:

CTO123I Control‑O INTERVAL IS SET TO nn SECONDS

Refreshing the Control-O Security Cache

Control‑O security modules use a security block to identify each user for which an authority check is performed. The first time a user’s security authorization is checked, Control‑O creates a security block for that user. The security block can then optionally be saved for the next time the user’s security authorization is checked.

Security blocks saved for subsequent checks are kept in the Control‑O Security Cache. The size of the security cache is defined in the RUNTCACH parameter in member CTOPARM. If 0 is specified for the RUNTCACH parameter, no security blocks are saved. For information, see the RUNTCACH parameter in the Control‑O chapter of the INCONTROL for z/OS Installation Guide: Installing.

The Control‑O Security Cache holds security blocks for only the last n users to have their security authorization checked, where n is the value specified for parameter RUNTCACH. For example, if parameter RUNTCACH contains a value of 10, the security cache holds a security block for each of the last ten users that were checked.

Changes made to a user’s security authorization since the last time that user’s security block was created are not automatically included in the information in the user’s security block in the Control‑O Security Cache. However if a user’s security authorization has been changed, and there is no security block in the Control‑O Security Cache for that user, changes made to the user’s security authorization are put into effect the next time that user’s security authorization is checked.

To immediately include new user authorization information in the Control‑O security cache, refresh the security cache using operator command

F CONTROLO,NEWSECDEF

This command refreshes all user authorization information in the Control‑O security cache.

When the modification is accepted, the following message is displayed on the operator console:

CTO251I RUNTIME SECURITY REFRESH ENDED OK

Problem Determination

Control‑O is supplied with internal debugging (trace) facilities that provide the ability to print an internal debugging trace and to print the contents of Control‑O internal data areas. Under normal circumstances, the trace facilities are dormant. However, if required (that is, if BMC Customer Support has requested debugging information), you can activate the trace facilities by performing the following steps:

Do one of the following:

1. Start a new ControlO monitor with the following operator command:

   Copy

   S CONTROLO,TRACE=level

   The ControlO monitor passes control to the new ControlO monitor and shuts down.

2. Issue the following operator command:

   The required trace level is supplied by BMC Customer Support. It can be any value from 000 to 255 (000 specifies no debugging).

   Copy

   F CONTROLO,TRACE=level

   You should not regularly activate ControlO with the TRACE parameter, because a JES problem may cause ControlO to become suspended while waiting for JES.

   Debugging information is printed to files referenced by DD statements DATRACE and DADUMP of the ControlO procedure.

3. When you finish your problem determination procedures, start a new ControlO using operator command

   Copy

   S CONTROLO

   or specify operator command

   Copy

   F CONTROLO,TRACE=00

Print Control-O Internal Data Areas

To print a snapshot of Control‑O internal data areas, issue operator command

F CONTROLO,SNAP[=name1,name2 .....,namen]

where name1, name2,.... namen are the names of the Control‑O internal data areas.

When no name is specified, all data areas are printed. Your BMC Customer Support can provide you with the list of data area names, and can specify which areas must be printed depending on the problem encountered.

Table 197 Valid Values for Data Areas

When the snap is completed, the following message is displayed on the console:

CTO150I SNAP COMMAND WAS PERFORMED SNAPID=xxxx

where xxxx is the snap identifying number (SNAPID) that is displayed at the lower right of the screen after the snap is completed.

Displaying Internal Resource Utilization Statistics

To obtain statistical information on internal resource utilization, issue the following operator command:

F CONTROLO,USAGESTATS[=type]

In this command, type designates the type of a specific internal resource.

Valid values for type in this command are RQC, PND, and WSC. When ALL is specified as a resource type, or when the parameter is omitted, information regarding all the above resource types is displayed.

The following is a typical sequence of messages displayed when this command is issued:

CTO356I USAGESTATS
CTO15EI RQC USAGE: CURRENTLY 1%, HIGHEST 1% (000001 AND 000019 OUT OF 010000)
CTO15EI PND USAGE: CURRENTLY 0%, HIGHEST 0% (000000 AND 000000 OUT OF 000011)
CTO15EI WSC USAGE: CURRENTLY 0%, HIGHEST 10% (000000 AND 000002 OUT OF 000020)
CTO357I COMMAND ENDED SUCCESSFULLY

For more information about these messages, see the INCONTROL for z/OS Messages Manual.

Control‑O users can tune the PND and WSC by adjusting the values of the WAITPR# and WSCs# parameters in the CTOPARM member. However, the RQC cannot be tuned. Look for any PTFs that correct problems handling RQC.

Displaying a Control-O Storage Table

To obtain information about Control‑O usage of internal storage areas, issue operator command

F CONTROLO,STORAGETABLE

Information message CTO356I is issued in response to this command. The figure shows an example of this message.

CTO356I STORAGETABLE   NAME         ADDRESS  LEN(HEX)  LEN(DEC)
   DEST         00D495C8 00000108  00000264
   FMIX         00000000 00000000  00000000
   INX          0370A390 000000E8  00000232
   MIX          036C0D28 00000504  00001284
   MSGB         00045190 00018E70  00102000
   PND          0358BAC8 00021534  00136500
   SRVR         03673EB8 00001144  00004420
   WSC          03614000 0001E000  00122880
   NETMAP       00C014A0 00003B60  00015200
   CTOWTO       831B3600 0002AA10  00174608 12/21/00 16.56 BO0709
   CTOAIDT      00BA6D58 000082B8  00033464 12/06/00 12.18 WO0818
   CTOALT       80B8FEC0 00003140  00012608 11/16/00 12.37
   CTOMTO       00006FB0 0003E050  00254032 01/09/01 13.15

For more information about these messages, see the INCONTROL for z/OS Messages Manual.

Control‑O users can tune the PND and WSC by adjusting the values of the WAITPR# and WSCs# parameters in the CTOPARM member. However, the RQC cannot be tuned. Look for any PTFs that correct problems handling RQC.

Displaying Major Control-O Blocks

To display information about major blocks used by Control‑O, issue operator command

F  CONTROLO,SHOWPARM

Information messages similar to the following are issued in response to this command:

CTO000I CTOPARM :CTOPARM  - 11/22/00 18.32 - Control‑O, REL 6.1.00      
CTO000I IOAPARM :IOAP 11/23/00 17.03 6.1.00
CTO000I CTMPARM :CTMP 11/23/00 17.03 6.1.00
CTO000I CTOPARM AT 000414F8
CTO000I ****....... CTOPARM  - 11/22/00 18.32 - Control‑O, REL 6.1.00
CTO000I FLAGS...... CTM         CTOQNAME... O51TROLO    INTERVAL... 0000040
CTO000I DAYTIME.... +1200       STSFL...... 0

The first messages issued indicate the compilation date and level of existing CTOPARM, IOAPARM and CTMPARM blocks.

Additional information (for example, the address of blocks in ECSA storage) is supplied in subsequent messages.

Changing Control-O’s Operating Mode

A special Control‑O operator command can be used to modify the operating mode of Control‑O. Under normal circumstances, Control‑O operating mode must not be modified. However, if severe Control‑O problems are detected and BMC Customer Support representative has requested debugging information, these commands can help isolate and solve the problem.

Use the following operator command to modify the Control‑O operating mode:

F CONTROLO,MODE[=modename]

where modename is the mode in which Control‑O must be run. The following modes can be specified:

Table 198 Control-O Operating Modes

CTO138I Control‑O OPERATING MODE IS NORMAL

The longer Control‑O automatic processes are halted (due to a MODE command), the more likely Control‑O’s examination of messages and commands will result in unexpected actions. Therefore, it is recommended that you stop Control‑O (using command P CONTROLO) and start Control‑O (using command S CONTROLO) as soon as a debugging session is complete.

Reacting to Events in a Sysplex Environment

Messages in a SYSPLEX Environment

Depending on the system configuration of a SYSPLEX environment, a message may be sent to another system. The SYSPLEX definition requires that at least one active console that is eligible to receive the message will be on the receiving system. This is done in order to reduce the overhead of distributing the message to too many systems unnecessarily.

Messages from another system are not logged in the system SYSLOG. They are logged on the SYSLOG of the original system and on the OPERLOG, if in use.

Control-O calls a message from another system a REISSUED message. The IBM term for such a message is a reissued or foreign message.

Control-O rules can be triggered for a reissued message only if the SYSTEM field in the ON MESSAGE, ON STRING, ON JOBARRIV, and ON JOBEND statements are set.

If the SYSTEM field is not set, the current system is assumed and therefore only messages from the current system will trigger the rule.

Control-O logs reissued messages in the Automation Log only if a rule is triggered for the reissued message.

In order to identify a reissued message, the following fields in the Automation Log should be set:

• SYSTEM = Original system name.

• SMFID = Current system SMFID. Control-O does not know the SMFID of the original system.

• J3FLG = R. The reissued or foreign message flag is on.

Commands in a SYSPLEX Environment

A command in a SYSPLEX environment is not send automatically to another member of the SYSPLEX. To send the command to another system, the user who entered the command must use the ROUTE command or system affinity character before the command.

• Control-O on the original system controls the route command or the command with the affinity character.

• Control-O on the receiving system receives the route command or the command with the affinity character

For example:

ROUTE SYSA,D T

The Control-O rule on the original system should be:

ON COMMAND ROUTE SYSA,*

The Control-O rule on system SYSA should be:

ON COMMAND DISPLAY T

The Control-O that receives the command has no indication that the command was originally issued from another system.

Other Control-O events in a SYSPLEX Environment

Other Control-O events like DSNEVENT, STEP, SYSOUT or MVALARM causes when the executing JOB or STC issues the event. That event can be triggered only by Control-O on the system where the job or STCs are executing.

In addition, Control-O roles that are triggered to messages from CICS, IMS and SYSOUTs are triggered on the system where the event occurred.

Customization of Automation Options

Automation Options (AOP) screens can be modified and new screens defined to meet site requirements. For a description of the Automation Options facility, see the introduction and online facilities chapters in the Control‑O User Guide.

AOP Overview

The Automation Options facility is comprised of the following components:

• Menu Definition Members

  Each menu definition is written in a member containing parameters (keywords and values) that describe the options in the menu. The following are defined for each option:

  • the name of the option

  • parameters that define the format of the display line

  • the name of the program to be executed or, for a submenu, name of the member containing the submenu definition

  Each Automation Option must have a menu definition member in the IOA MSG library. The name of this member must be the name of the menu, prefixed by ##. For example, the definition for menu OPER must reside in member ##OPER.

  • The main Automation Options menu is defined in member ##AOP.

  • To update or add an Automation Option, it is necessary to access the appropriate menu definition member and modify it.

• Format Members

  Formats describe how lines provided by a client program are to be displayed on the screen. The format of the primary Automation Options screen provided by Control-O is specified in member $$AOP in the IOA MSG library. The user can write new formats and save them as members in the MSG library.

  • To avoid problems in the execution of the Automated Options facility, do not modify member $$AOP.

• Client programs

  Client programs can be any independent load module, TSO CLIST, or REXX EXEC, which the Automation Options facility invokes either to perform functions or to provide lines to be displayed.

Menus

Update the appropriate member in the IOA MSG library with the parameters of the new options. Each parameter described in this section defines a line in the specification of the new Automation Option.

Menu Member Syntax

The following syntax rules must be considered when defining menus of new options:

• A menu statement consists of one or more lines, each with of a maximum of 72 columns.

• Each menu statement is comprised of a parameter (keyword and its value), separated by one or several blank spaces. Parameters can be specified in uppercase or lowercase.

• Data can be specified anywhere between columns 1 and 71.

• A non-blank character in column 72 indicates that the statement is continued on the next line.

• Data on continuation lines must start at column 16.

An asterisk (*) in column 1 specifies that the line is a comment.

AOP Parameters

Table 199 Mandatory Parameters

 OPTION USERINFO NOPAD

Table 200 Optional Parameters

 PROMPT   '  COMMAND       ===>',4 PROMPT   '                ===>',3
 SET      '%%A1=%%$SUBSTR %%P1 1 3'
 SET      '%%A2=%%$SUBSTR %%$TIME 1 3'
 SET      '%%A3=%%$DATE'
 PARM     '%%P1.%%P2.%%A1%%.%%$BLANK.%%A2.%%$BLANK.%%A3'

NOSCREEN, TSOCP, or EXECPGM.

FORMAT $$UINFO

SubMenu Examples

PROMPT   '  COMMAND       ===>',4                         
PROMPT   '                ===>',3                         
SET      '%%A1=%%$SUBSTR %%P1 1 3'                        
SET      '%%A2=%%$SUBSTR %%$TIME 1 3'                     
SET      '%%A3=%%$DATE'                                   
PARM     '%%P1.%%P2.%%A1%%.%%$BLANK.%%A2.%%$BLANK.%%A3'   

PROGRAM AOPGUINF

PROGRAM SDSF IMMEDIATE NOSCREEN TSOCP

PROGRAM CLIST1 IMMEDIATE NOSCREEN TSOCP

PROGRAM CTOTAMN
OPTLIST ##SAMPLE

PROGRAM  CTOTPB1 SUBMENU(##PBOOK2)

PROMPT Format

PROMPT data1,length,data2

Table 201 Fields for PROMPT

PROMPT Examples

PROMPT 'User name ====>>',8

PROMPT 'Department ====>>',20,'TECH-SUPPORT'

PARM Examples

Functions such as %%$SUBSTR can also be specified.

After AutoEdit symbols have been resolved, the string’s length cannot exceed 255 characters.

PARM #00' '77#

QUERY,USERID=UserA,DEPARTMENT=TECH-SUPPORT

PROMPT 'User name ====>>', 8
PROMPT 'Department ====>>',20,'TECH-SUPPORT'
PARM /QUERY,USERID=%%P1,DEPARTMENT=%%P2/

RETURNS Example

Divide the returned lines into the following displayable variables:

Table 202 Variables that Can Be Displayed

RETURNS '1 FIRSTNME +8 20 LASTNME +12 60 ADDRESS +35'

These variables must be defined in the corresponding format member.

RETURNS cannot be specified for programs specifying NOSCREEN.

OPTION USERINFODESC 'Query USER database'
LINECMD S
PROGRAM CTOTAMN
OPTLIST ##UINFO FORMAT $$AOP
RETURNS '1 OPTION +8 9 DESC +60'

Format Members

Format members are used to format the lines displayed on the screen. For details on how to define and customize format members, see IOA Administration

Client Programs

A client program is a load module, TSO CLIST, or REXX EXEC that is invoked by the Automation Options facility when selected by a line command character (other than ?). Client programs can be called, with or without parameters, to perform a function and then return without displaying lines.

Sophisticated AOP programs receive parameters using PROMPTs or PARM statements, and return lines for display or as a submenu to have more selections or action windows. Before a program is called, the Automation Options facility reviews program attributes in the menu and takes special actions if necessary.

Examples

If ISPFENV is specified, the Automation Options facility ensures that a valid ISPF environment exists before invoking the client program.

If IMMEDIATE is specified, the Automation Options facility checks the PROMPTs and the PARM specification in the menu, if any, and passes the data to the client program without displaying it on the screen.

General registers 1 through 15 contain the following information at the time of entry to the client program:

Table 203 Information Stored in Registers 1 Through 15

Program Input

The program input varies according to the type of client program: EXECPGM, TSOCP, or AOP or SUBMENU. A full description of the input data is included in member DOCOAOCP in the DOC library.

Execution Process

Client programs of the TSOCP or EXECPGM type must follow these rules:

• Consider the program to be an extension of IOA. Because it runs under IOA, an abend of the client program triggers an abend of the IOA session. Storage overlays within the program may produce unpredictable results.

• Registers must be saved and restored according to standard IBM conventions.

• Areas acquired by the program during execution must be released before returning to the Automation Options facility. Failure to follow this rule may result in storage buildup and cause abends.

• CLISTs and REXX EXECs can be used under MVS/XA or higher level operating systems.

• Client programs that are not of type TSOCP or EXECPGM are called AOP programs. A full description of the execution process of an AOP program is included in member DOCOAOCP in the DOC library.

Client Program Linkage Conventions

Client programs that do not specify attributes NOSCREEN, TSOCP, EXECPGM or SUBMENU, return a set of lines to the Automation Options facility. These lines are displayed according to the parameters specified in the format member referenced by the FORMAT statement in the menu definition member.

Client programs that specify attribute SUBMENU return a list of menu option lines to the Automation Options facility. These menu option lines are displayed according to the parameters specified in the OPTION member named by the SUBMENU keyword in the FORMAT member. You can specify line commands for each line of the submenu.

A full description of the Client Program Linkage Conventions for an AOP program is included in member DOCOAOCP in the IOA DOC library.

An example of SUBMENU usage (using a phone book scenario) can be found in member CTOTPB$ in the IOA SAMPLE library.

Control-O and Control-M in the Same INCONTROL Environment

The following topics discuss issues to consider when both Control‑O and Control‑M are running in the same INCONTROL environment.

After Installing Control-O and Control-M

When Control‑O and Control‑M are running together, the Control‑O monitor assumes the responsibilities of both the CMEM facility and Control‑O. The way in which the Control‑O monitor functions depends on how organizational requirements, scheduling, and automation have been addressed at your site.

The following table describes the DD statements in the Control‑O startup procedure that are relevant to this issue:

Table 204 Relevant DD Statements in Control-O Startup Procedure

The Control‑O monitor can operate in the following ways:

• If all automation was implemented using only the Online ControlO Rule Definition facility, and the CMEM facility was not used, start ControlO using operator command

  Copy

  S CONTROLO

  ControlO loads the rule tables listed in the member referenced by DD statement DARULLST. The member referenced by DD statement DACTMLST must be empty.

• If automation was implemented using both the ControlO Rule Definition facility and the CMEM facility, start ControlO using operator command

  Copy

  S CONTROLO

  ControlO first loads the CMEM rule tables listed in the member referenced by DD statement DACTMLST. ControlO then loads the ControlO rule tables listed in the member referenced by DD statement DARULLST.

• If automation was implemented using both the ControlO Rule Definition facility and the CMEM facility but, temporarily, only CMEM functionality is desired (for example, for a trial period), start ControlO using the following operator command:

  Copy

  SCONTROLO,TYPE=CTOCMEM

  This command causes the ControlO monitor to load only CMEM rule tables. ControlO loads the CMEM rule tables listed in the member referenced by DD statement DACTMLST. Loading of ControlO tables is skipped. Do not use this mode of operation on a long-term basis.

More information on the management of the CMEM facility by the Control‑O monitor is provided at the beginning of this chapter.

Accessing the Control-M API

If a Control‑O rule queries the Control‑M Active Jobs file (AJF) or the Control‑M Resources file, it accesses them through the Control‑M API (CTMAPI).

When maintenance of the AJF and Control‑M Resources file is required, you can stop and restart Control‑O allocation of the AJF and the Control‑M Resources file through the CTMAPI, without having to stop Control‑O. To do this, use the following commands:

Table 205 Commands to Control Access of the CTMAPI

F CONTROLO,CTMAPISTOP

F CONTROLO,CTMAPISTART

For a description of the messages generated by these commands, see the INCONTROL for z/OS Messages Manual.

Control-O/CICS Interface

Although regular Control‑O processing can handle CICS messages that are sent to the MVS console, most CICS messages are not sent to the MVS console. CICS sends messages to an internal component called the Transient Data Queue and sometimes to the user console as well.

The Control‑O/CICS interface enables you to retrieve these messages.

Control-O Interface for the CICS Environment

The Control‑O/CICS interface uses the CICS XTDOUT exit to intercept CICS messages that are to be sent to the Transient Data Queue. This exit receives control before each message is written to the Transient Data Queue and passes it to the Control‑O/CICS interface module CTOCTDX. Module CTOCTDX passes the message to the Control‑O WTO executor module (CTOWTO) as a WTO message. Module CTOWTO determines whether the message must be untouched, changed, or suppressed (that is, not written to the Transient Data Queue).

Starting the Interface

The Control‑O/CICS interface can be started in either of the following ways:

Table 206 Methods for Starting Control-O/CICS

IOAC INIT

IOAC Transaction Options

The table describes the options that can be specified for a CICS IOAC transaction.

Table 207 Methods for Starting Control-O/CICS

Control-O/IMS Interface

Although regular Control‑O processing can handle IMS messages that are sent to the MVS console, most IMS messages are not sent to the MVS console. IMS messages that are not sent to the MVS console are sent to an internal component called the Automated Operations Interface (AOI). The Control‑O/IMS interface enables you to retrieve and respond to these messages.

Depending on the IMS version in use at your site, one of the following IMS AOI programs is used to handle messages:

Table 208 IMS AOI Programs for Handling Messages

These programs are supplied with Control‑O and are implemented during Control‑O installation. These programs intercept IMS messages sent to the IMS Automation Interface and pass them to Control‑O WTO executor module CTOWTO. The CTOWTO module determines whether the message must be untouched, changed, or suppressed.

Operating the Control-O/IMS Interface

The Control‑O/IMS interface is implemented using the Automated Operations Interface (AOI). AOI starts when the IMS environment is initiated, if either module DFSAOUE0 is link-edited into the IMS nucleus or module DFSAOE00 is found in the IMS RESLIB library.

The AOI can be stopped in either of the following ways:

• Stop the IMS environment and delete module DFSAOE00 from the IMS RESLIB library.

• Stop the ControlO/IMS interface using a ControlO/IMS command.

Control-O/IMS Commands

The Control‑O/IMS interface is activated when IMS is brought up. The following table describes the commands that can be used with Control‑O/IMS interface module DFSAOE00:

Table 209 Commands for Use with Control-O/IMS Interface Module

Control-O MAINVIEW Alarm Interface

Control‑O provides a special interface to support ON MVALARM events originating from the MAINVIEW Alarm environment. For a description of the ON MVALARM parameter, see the chapter that discusses rule parameters in the Control‑O User Guide.

Controlling MAINVIEW Alarm Support (ON MVALARM Rules)

The AutoOPERATOR interface is shared among all Control-O installations in a site, whether or not the Control-O version is 6.2 or later. The first Control-O subsystem to initialize among all Control-O installations loads the AutoOPERATOR interface module into common storage, which is later used by all other Control-O subsystems. Upon startup, each subsystem registers itself with the AutoOPERATOR interface. This registration mechanism enables the AutoOPERATOR interface to recognize all available Control-O subsystems and to call them when the AutoOPERATOR interface is driven.

When a Control-O subsystem shuts down, it removes itself from the MAINVIEW interface. The last Control-O subsystem to shut down completely removes the AutoOPERATOR interface from common storage.

Control-O MAINVIEW Commands

Control‑O enables the operator to start and stop the MAINVIEW interface using the Modify operator command. The following operator commands are available:

F CONTROLO,STARTMVI
F,CONTROLO,STOPMVI,FORCE

Starting the MAINVIEW Interface

The STARTMVI command instructs a Control‑O subsystem to restart the MAINVIEW interface. This includes a possible initialization of the interface, if it has not yet been initialized by another subsystem or registration of the current subsystem in the MAINVIEW interface. If the STARTMVI command is issued for a subsystem that is already registered with the MAINVIEW interface, the following message is displayed:

CTO848I SUBSYSTEM ALREADY REGISTERED WITH MAINVIEW
        INTERFACE

Stopping the MAINVIEW Interface

The STOPMVI command instructs a Control‑O subsystem to deactivate the MAINVIEW interface. This includes removing the registration of the current subsystem from the MAINVIEW interface, and possibly removing the MAINVIEW interface from common storage, if no other subsystems are using it. When issuing the STOPMVI command for a subsystem that is not registered with the MAINVIEW interface, the following message is displayed:

MTO84HW SUBSYSTEM NOT REMOVED FROM MAINVIEW
        INTERFACE: SUBSYSTEM NOT FOUND

When issuing the STOPMVI command when no MAINVIEW interface is present, the following message is displayed:

MTO84GW MAINVIEW INTERFACE MODULE NOT INSTALLED

Forcing the MAINVIEW Interface to Stop

The STOPMVI,FORCE command instructs Control‑O to remove the MAINVIEW interface from common storage, regardless of any registered subsystems.

Control‑O also provides a procedure named CTOMVDSC that can be started from the console using the START command. This procedure acts like a STOPMVI,FORCE command, and removes the MAINVIEW interface regardless of any registered subsystems.

The STOPMVI,FORCE command and the CTOMVDSC procedure must be used only in case of emergency.

Control-O MAINVIEW AutoOPERATOR interface

Control-O and CMEM provide a special interface to support MAINVIEW AutoOPERATOR version 5.1 and later, using the ON AOREQ rule to enable AutoOPERATOR to communicate with Control-M, Control-D, and IOA through Control-O rules.

The AOREQ rule is part of the AutoOPERATOR product.

For a description of the ON AOREQ parameter, see the chapter that discusses rule parameters in the Control-O User Guide.

Controlling MAINVIEW AutoOPERATOR support (ON AOREQ rules)

Controlling MAINVIEW Alarm Support (ON MVALARM Rules)

The AutoOPERATOR interface is shared among all Control-O installations in a site, whether or not the Control-O version is 6.2 or later. The first Control-O subsystem to initialize among all Control-O installations loads the AutoOPERATOR interface module into common storage, which is later used by all other Control-O subsystems. Upon startup, each subsystem registers itself with the AutoOPERATOR interface. This registration mechanism enables the AutoOPERATOR interface to recognize all available Control-O subsystems and to call them when the AutoOPERATOR interface is driven.

When a Control-O subsystem shuts down, it removes itself from the MAINVIEW interface. The last Control-O subsystem to shut down completely removes the AutoOPERATOR interface from common storage.

Starting the AutoOPERATOR interface

The STARTAAO command instructs a Control-O subsystem to restart the AutoOPERATOR interface. This includes a possible initialization of the interface, if it was not yet initialized by another subsystem or by registration of the current subsystem in the AutoOPERATOR interface.

Either of the following message sequences indicates a successful installation of the AutoOPERATOR interface:

• for the first Control-O subsystem to initialize:

  Copy

  CTO83AI INITIALIZATION OF AUTOOPERATOR SUPPORT STARTED          
  CTO83EI SUBSYSTEM REGISTERED WITH AUTOOPERATOR INTERFACE        
  CTO83FI INITIALIZATION OF AUTOOPERATOR SUPPORT ENDED SUCCESSFULLY

• for any subsequent Control-O subsystem that initializes:

  Copy

  CTO83EI SUBSYSTEM REGISTERED WITH AUTOOPERATOR INTERFACE        
  CTO83FI INITIALIZATION OF AUTOOPERATOR SUPPORT ENDED SUCCESSFULLY

Stopping the AutoOPERATOR interface

The STOPAAO command instructs a Control-O subsystem to deactivate the AutoOPERATOR interface. This includes removing the registration of the current subsystem from the AutoOPERATOR interface, and possibly removing the AutoOPERATOR interface from common storage, if no other subsystems are using it.

Either one of the following message sequences indicates a successful deactivation of the MAINVIEW interface:

• For all but the last Control-O subsystem to shut down:

  Copy

  CTO83KI DEACTIVATION OF AUTOOPERATOR SUPPORT STARTED             
  CTO83OI SUBSYSTEM REGISTRATION REMOVED FROM AUTOOPERATOR INTERFACE
  CTO83QI DEACTIVATION OF AUTOOPERATOR SUPPORT ENDED SUCCESSFULLY  

• for the last Control-O subsystem that shuts down:

  Copy

  CTO83OI SUBSYSTEM REGISTRATION REMOVED FROM AUTOOPERATOR INTERFACE
  CTO83QI DEACTIVATION OF AUTOOPERATOR SUPPORT ENDED SUCCESSFULLY  

Forcing the AutoOPERATOR interface to stop

The STOPAAO,FORCE command instructs Control-O to remove the AutoOPERATOR interface from common storage, regardless of any registered subsystems.

Use the STOPAAO,FORCE command only in case of emergency.

Control-O SMS Interface

Control‑O provides a special interface to support ON SMS events originating from SMS ACS exit routines.

Controlling SMS Support (ON SMS Rules)

The SMS interface is shared among all Control‑O installations in the site and therefore is version-independent. The first Control‑O subsystem to initialize loads the SMS interface module to common storage that is later used by all other Control‑O subsystems. Every subsystem, upon startup, registers itself with the SMS interface. This registration mechanism allows the SMS interface to recognize all available Control‑O subsystems and to call them when one of the provided ACS exit routines is driven.

When a Control‑O subsystem shuts down, it removes itself from the SMS interface. The last Control‑O subsystem to shut down also removes the SMS interface completely from common storage.

Either of the following message sequences indicates a successful installation of the SMS interface:

• for the first ControlO subsystem to initialize

  Copy

  CTO820I INITIALIZATION OF SMS SUPPORT STARTED
  CTO821I SMS INTERFACE MODULE SUCCESSFULLY LOADED
  CTO822I SUBSYSTEM REGISTERED WITH SMS INTERFACE
  CTO823I INITIALIZATION OF SMS SUPPORT ENDED
          SUCCESSFULLY

• for any subsequent ControlO subsystem that initializes

  Copy

  CTO820I INITIALIZATION OF SMS SUPPORT STARTED
  CTO822I SUBSYSTEM REGISTERED WITH SMS INTERFACE
  CTO823I INITIALIZATION OF SMS SUPPORT ENDED
          SUCCESSFULLY

Either one of the following message sequences indicates a successful deactivation of the SMS interface:

• for any ControlO subsystem to shut down, except for the last in the system

  Copy

  CTO830I DEACTIVATION OF SMS SUPPORT STARTED
  CTO831I SUBSYSTEM REMOVED FROM SMS INTERFACE
  CTO833I DEACTIVATION OF SMS SUPPORT ENDED
          SUCCESSFULLY

• for the last ControlO subsystem that shuts down

  Copy

  CTO830I DEACTIVATION OF SMS SUPPORT STARTED
  CTO831I SUBSYSTEM REMOVED FROM SMS INTERFACE
  CTO832I SMS INTERFACE MODULE REMOVED
  CTO833I DEACTIVATION OF SMS SUPPORT ENDED
          SUCCESSFULLY

Control-O/SMS Commands

Control‑O provides means for the operator to start and stop the SMS interface using the Modify operator command.

Usually, there is no need to intervene with the default processing taken by Control‑O. The following operator commands are available:

F CONTROLO,STARTSMS
F,CONTROLO,STOPSMS,FORCE

The STARTSMS command instructs a Control‑O subsystem to restart the SMS interface. This includes a possible initialization of the interface (if it has not yet been initialized by another subsystem), and/or registration of the current subsystem in the SMS interface. If the STARTSMS command is issued against a subsystem that is already registered with the SMS interface, the following message is issued:

CTO828I SUBSYSTEM ALREADY REGISTERED WITH SMS
        INTERFACE

The STOPSMS command instructs a Control‑O subsystem to deactivate the SMS interface. This includes unregistration of the current subsystem from the SMS interface, and a possible removal of the SMS interface from common storage, if no other subsystems use it. When issuing the STOPSMS command against a subsystem that is not registered with the SMS interface, the following message is issued:

MTO836W SUBSYSTEM NOT REMOVED FROM SMS
        INTERFACE: SUBSYSTEM NOT FOUND

When issuing the STOPSMS command when no SMS interface is present, the following message is issued:

MTO835W SMS INTERFACE MODULE NOT INSTALLED

The STOPSMS,FORCE command instructs Control‑O to remove the SMS interface from common storage, regardless of any registered subsystems.

Control‑O also provides a started procedure named CTOSMDSC that can be started from the console using the START command. The CTOSMDSC procedure acts like a STOPSMS,FORCE command, and removes the SMS interface regardless of any registered subsystems. The STOPSMS,FORCE command and the CTOSMDSC procedure must be used only in case of emergency.

Starting Control-O Communication Support (IOAGATE)

Verify that the IOA Gateway has been successfully installed before trying to start IOAGATE. For information about installing the IOA Gateway, see the IOA chapter in the INCONTROL for z/OS Installation Guide: Installing.

Verify that Control‑O table CTOGATEI is loaded from the Control‑O Rules library. This rule table includes a set of rules that executes the remote request. It must be loaded for every Control‑O monitor that communicates using IOAGATE, Sysplex or Control‑O/COSMOS in a Sysplex.

1. To start IOAGATE processing, first initialize the mainframe components. ControlO users can then proceed to use the communication channel.

2. Activate the IOA Gateway using operator command:

   Copy

   S IOAGATE

   ECAPARM communication parameters (APPLIDS, PORT) can be overridden by parameters specified in the EXEC PARM of IOAGATE. For information about ECAPARM parameters, see the IOA chapter of the INCONTROL for z/OS Installation Guide: Installing.

   Copy

   S IOAGATE,APPLID=CTOLUA1

   The ControlO Application Server (called CTOAS) is automatically activated by the IOA Gateway.

3. To deactivate the IOA Gateway, use operator command

   Copy

   P IOAGATE

   This also deactivates the ControlO Application Server (CTOAS).

Displaying a List of All Active Users

To display the list of all active users in the Application Server, use operator command

F IOAGATE,MODASID[=nn] D[ISPLAY]

where nn is the specific address space ID of the server to which the modify command is submitted. If no address space is specified, the modify command is submitted to all active server address spaces.

When D [DISPLAY] is specified, a list of all active sessions are displayed.

Considerations

When Control‑O and IOAGATE are installed, the following modify commands are available:

These commands are available only if parameter CTOGATE is set to YES in member CTOPARM.

For a list of systems to which Control‑O is connected to the IOAGATE and using Sysplex, issue the following command:

F CONTROLO,DISPCOMM

In the case of Sysplex, the first Sysplex name is also listed.

The following is displayed as a result of this command:

CTO356I DISPCOMM             
Control‑O COMMUNICATION MAP  
VTAM CONNECTIONS:            
NAME     LU           APPL       
CTO01    CTOLU01  O          
CTO03    CTOLU03  O          
SYSPLEX CONNECTIONS:         
ESA1

• To enable communication after the STOPCOMM modify command was issued, use the command

  Copy

  F CONTROLO,STARTCOMM

  This command is available only if parameter CTOGATE is set to YES in member CTOPARM and if communication was stopped.

• To disable communication in ControlO, use the command

  Copy

  F CONTROLO,STOPCOMM

  This command is available only if parameter CTOGATE is set to YES in member CTOPARM and if communication was started.

• During problem determination, to snap the system network map, use the command

  Copy

  F CONTROLO,SNAP=SYS

Problem Determination

To enable or disable debug messages, specify operator command

F CTOAS,DEBUG=(nn[,‑nn]...)

where nn enables and –nn disables debug action nn in the following table:

Table 210 Fields for Problem Determination