Implementation

This chapter includes the following topics:

Introduction

This chapter describes Control-O/COSMOS implementation. It is highly recommended that you read this entire chapter before performing the tasks described below.

Control-O/COSMOS Configuration

This section describes files used by Control-O/COSMOS that must be modified to enable Control-O/COSMOS to access relevant databases, and to trigger Control-O/COSMOS rules.

RULELIST Member

This member (also known as the Control-O Rule Table list) is a list of all rule tables to be loaded during Control-O startup. This member is located in the Control-O PARM library.

Verify that all Control-O/COSMOS rule tables are listed in this member.

Before verifying these rule tables, consider the following:

  • If Control-O/COSMOS was installed during Control-O installation, the necessary rule tables are already referenced in the Control-O Rule Table list (RULELIST member).

  • If Control-O/COSMOS was not installed during Control-O installation, ensure that the Control-O/COSMOS rule table is listed in the RULELIST member that is referenced in the Control-O startup procedure.

  • To use the COSMOS Sysplex support, load the CTOGATEI table, which supports communications, in addition to the COSMOS tables.

DAGLBLST Member

All Control-O/COSMOS databases must be listed in the Control-O Global Variable Pool list (member DAGLBLST). The following databases must be listed:

  • All Object databases.

  • All Method databases.

  • The Prerequisite database.

Member DAGLBLST is located in the Control-O PARM library. This member is checked during Control-O startup for the names of all Global variable members and Variable databases. Listing Control-O/COSMOS databases in this member ensures that the databases are loaded when Control-O is started and that they are accessible to the AutoEdit facility (that is used to manage these databases).

A series of Global variables are defined during Control-O/COSMOS initialization. By default, these variables are stored in Global variable pool COSWORKV. Verify that this Global variable pool is listed in the DAGLBLST member. If Control-O/COSMOS was installed during the Control-O installation process, Control-O/COSMOS variable databases and the Control-O/COSMOS Global variable pool COSWORKV may have already been added to this member.

This member must be changed when the XAE type 1 database is used in a Sysplex, as described in Using Control-O/COSMOS to Manage a Sysplex

For more information about Variable databases, see the online variable database definition discussion in the online facilities chapter of the Control-O User Guide.

The AutoEdit facility is described in the AutoEdit facility chapter of the Control-O User Guide.

Methods for managing variables in a variable database are described in the description of the DO SET parameter in the rule parameters chapter of the Control-O User Guide.

Control-O Variable Database Files

Control-O/COSMOS databases are stored together with all other variable databases in the Control-O variable database files. Verify that the size specified for these files is sufficient for expected Control-O/COSMOS databases.

For more information, see the Control-O chapter of the INCONTROL for z/OS Administrator Guide.

Using Control-O/COSMOS to Manage a Sysplex

You can use XAE type 1 databases with the Control-O/COSMOS Working Object Databases. With XAE type 1 databases, users that are logged on to one system can see the objects of different Sysplex participants, and can manage them from a single screen. For example, a user logged on to SYSTEM A can start or stop an object running on SYSTEM B.

To enable Control-O/COSMOS to manage a Sysplex, each line in member DAGLBLST that defines a working database must be changed (for example, from DBTEMP to S1TEMP). In addition, the CTOGATEI table must be loaded from the RULELIST member in the CTOprefix.RULES library.

When you use Control-O/COSMOS to manage a Sysplex, if you are defining CPU names within member COSMOLST, (for more information, see COSMOLST Member), you must use the exact name of each CPU’s corresponding system name as defined in the Sysplex environment.

COSMOLST Member

The COSMOLST member in the Control-O PARM library contains basic information about all Object databases to be managed by Control-O/COSMOS. The information in the COSMOLST member is used by:

Control-O/COSMOS at initialization, to determine information about the working environment.

Control-O/COSMOS initialization rules, described in Component Details, to determine values for Global AutoEdit variables used by Control-O/COSMOS rules.

Control-O/COSMOS to generate the Control-O/COSMOS Database Status screen.

A sample COSMOLST member is shown below:

Figure 16 Sample COSMOLST

Copy
H FREE     COSALLPR 00000000 000000000
T COSSTCSD COSSTCOB COSALLMT FREE     UP       DOWN     UNKNOWN
T COSVTMSD COSVTMOB COSALLMT FREE     ACTIVE   INACTIVE UNKNOWN
T COSIMGSD COSIMGOB COSALLMT FORCE_OK UP       DOWN     UNKNOWN
C ESA1     ESA2     ESA3     ESA4     ESA5     ESA6     ESA7

Format of the COSMOLST Member

The first column of each record in member COSMOLST indicates the type of record in the line. Valid values are:

H – Header record

T – Object Database record

C – CPU record

Valid format for COSMOLST records of each type are described below.

Header Record

Only one header record can be specified. It contains general information about Control-O/COSMOS.

Table 24 Header Record

Columns

Description

03-10 Default system wide Control-O/COSMOS operating mode at startup. Valid values are FREE, HELD, FORCE_OK and NOPRE.
12-19 Name of the Control-O/COSMOS Prerequisite database.
21-28 Operational flags. For future use (now all zeroes).
30-37 Control-O/COSMOS flags. If set to Y, a COSFSMPR message is issued for each missing prerequisite.

Object Database Record

One or more database records can be specified. They contain information related to each Object database.

CPU Record

Table 25 CPU Record Description

Columns

Description

03-10 Name of the Source Object database.
12-19 Name of the Working Object database.
21-28 Name of the Method database associated with this Object database.
30-37 Default mode of the database at startup. valid values: FREE, HELD, FORCE_OK, and NOPRE.
39-46 Name of the UP status (for example, UP, ONLINE or ACTIVE) for objects in the Object database.
48-55 Name of the DOWN status (for example, DOWN, OFFLINE or INACTIVE) for objects in the Object database.
57-63 Name of the UNKNOWN status (for example, UNKNOWN or NOTFOUND) for objects in the Object database.

CPU records are used to indicate the system name or the SMF ID of CPUs in your environment. Each CPU name specified in a CPU record is stored in a variable when Control-O/COSMOS is activated. These variables can be referenced at your convenience using Control-O rules.

When using Control-O/COSMOS to manage a Sysplex, as described in Working With the Control-O/COSMOS Demo Environment, if you want to be able to browse several systems from the online screen, you must define each CPU name using its corresponding system name, as defined in the Sysplex environment.

Table 26 CPU Name Definitions

Column

CPU

03-10 CPU name 1
12-19 CPU name 2
21-28 CPU name 3
30-37 CPU name 4
39-46 CPU name 5
48-55 CPU name 6
57-63 CPU name 7

One or more CPU records can be specified.

Testing Control-O/COSMOS Operations

A set of supplied demo Control-O/COSMOS databases can be used to manage a set of simulated Control-O/COSMOS objects. Actions performed with these objects cause actual messages to be issued, but are used to manage simulated objects, not the real objects in your computing environment.

Use the Control-O/COSMOS demo environment to familiarize yourself with Control-O/COSMOS commands and options without affecting your system, and to test modifications to Control-O/COSMOS rules before implementing them in the production environment.

Simulated objects in the Control-O/COSMOS demo environment issue messages that are identical to certain messages issued by true objects in your production environment. To avoid inadvertently affecting objects in your production environment, if you already have automation rules in use at your site that respond to these messages (for example, startup messages), ensure that these automation rules are disabled while you are working in the Control-O/COSMOS demo environment.

Components

The following components are supplied as part of the Control-O/COSMOS demo environment:

procedures that simulate messages issued by common started tasks

object database describing started tasks

Actions on objects in this database simulate actions on real started tasks. Starting or stopping a demo started task produces the same messages as starting or stopping a real started task without actually starting or stopping the real started task.

For example, procedure xxxJES2 (the demo JES2 object) issues the same messages that JES2 issues when it is started or stopped. IPL or shutdown can be simulated without the need to initialize or shut down the computer.

To enable running several demo systems in the same CPU the demonstration database object name prefixes are changed, in the COSINI command code, from CTO to the PROCPRFO prefix.

For example, if the PROCPRFO prefix is "O60," an object named CTOJES2 is renamed to O60JES2.

Object database containing demo VTAM LUs

Prerequisite database describing interdependencies of objects in the demo Object databases

Empty Object database (only the columns are defined) used to store started task objects defined by the SYSIMAGE facility. This database helps demonstrate how Control-O/COSMOS handles your production environment.

Demo Method database

This Method database contains descriptions of some of the methods required to manage objects in the Object databases of the demo environment.

Control-O/COSMOS rules of all types. Control-O/COSMOS rules are described in Component Details.

Method rules supplied with Control-O/COSMOS demonstrate basic management of Control-O/COSMOS-controlled objects. These rules can later be used as a basis for creation of additional rules used to manage objects in your production environment.

Demo Databases Supplied With Control-O/COSMOS

The following demo databases are provided:

Table 27 Demo Databases

Database

Description

COSALLPR

Demo Prerequisite database.

COSALLMT

Demo Method database.

COSSTCOB

Demo Working Object database for started task objects.

COSVTMOB

Demo Working Object database for VTAM objects.

COSIMGOB

Demo Working Object database for objects defined using the SYSIMAGE facility, described in SYSIMAGE Facility – Automatic Generation of an Object Database.

When the input file for the SYSIMAGE facility is properly customized, modify the SYSIMAGE rules to build objects in the appropriate production Object database.

COSSTCSD

Demo Source Object database for started task objects.

COSVTMSD

Demo Source Object database for VTAM objects.

COSIMGSD

Demo Source Object database for objects defined using the SYSIMAGE facility, described in SYSIMAGE Facility – Automatic Generation of an Object Database.

 

Working With the Control-O/COSMOS Demo Environment

You can use the Control-O/COSMOS demo environment to familiarize yourself with Control-O/COSMOS functions (screens, commands, and so on). Use the following steps to guide you through Control-O/COSMOS.

  1. Start Control-O (if it is not already active).

  2. Start Control-O/COSMOS using command xxxINI (if this command was not already issued by a rule at Control-O/COSMOS startup).

  3. Enter the Control-O/COSMOS Object Status screen using option OBJECT in the Control-O/COSMOS Main menu (screen OC). You can use this screen to view the current status of Control-O/COSMOS-controlled objects.

  4. Exit the Object Status screen, and issue operator command xxxUP. This command sets the mode of demo Object databases to FREE and specifies UP as the desired status for each object.

  5. Return to the Object Status screen to observe how Control-O/COSMOS-controlled objects are handled as a result of command xxxUP.

  6. Control-O/COSMOS-controlled objects are brought up in the order dictated by prerequisites defined in the demo Prerequisite database (for example, xxxJES2 is brought up before xxxVTAM, followed by applications that require VTAM to be up).

  7. When all Control-O/COSMOS-controlled objects have a status of STEADY UP, issue command xxxDOWN.

  8. Objects are brought down in the reverse order from which they were brought up. This is due to inverse application of Control-O/COSMOS prerequisites.

  9. Use the SYSIMAGE Facility – Automatic Generation of an Object Database to build an Object database that reflects your production environment.

    Objects defined using the SYSIMAGE facility are assigned a mode of FORCE_OK. This ensures that objects in your production environment are not modified by Control-O/COSMOS while operating in a demo environment.

    For more information about the SYSIMAGE facility, see SYSIMAGE Facility – Automatic Generation of an Object Database, and the CTOCTI utility in the INCONTROL for z/OS Utilities Guide.

  10. Experiment with options in the Object Status screen and the Database Status screen. For more information about these screens, see Online Facilities.

  11. Review the rules supplied with Control-O/COSMOS, and familiarize yourself with their logic.

SYSIMAGE Facility – Automatic Generation of an Object Database

The SYSIMAGE facility is used to automatically generate an object database that reflects your working environment. Table 28 describes the components that make up the SYSIMAGE facility:

Table 28 SYSIMAGE Facility Components

Item

Description

CTOCTI utility

This utility, located in the JCL library, scans the system for started tasks, and issues messages with started task information.

An input file for the CTOCTI utility is used to specify information about started tasks in your environment. Ensure that the information in this file is as complete and accurate as possible, so that the automatically generated object database contains an accurate description of your environment.

For more information about the CTOCTI utility, see the INCONTROL for z/OS Utilities Guide.

CTOCTA utility

This utility, located in the JCL library, provides the names of programs to be executed from a specified address space. This helps determine the information to be included in the input file for the CTOCTI utility.

For more information about the CTOCTA utility, see the INCONTROL for z/OS Utilities Guide.

CTO659I rule

A Control-O rule triggered by message CTO659I, issued by the CTOCTI utility.

This rule creates an object database row for each occurrence of the message, according to information in the message.

By default, the rule inserts rows in object database COSIMGSD. This object database is defined in the DAGLBLST member with an attribute of DBINPUT, which means that no changes can be made to this database.

This rule can be customized, for example, to automatically create rows in the prerequisite database or method definitions in a method database.

To implement the SYSIMAGE facility, perform the following steps:

  1. Run the CTOCTI utility to identify started tasks that were not defined in the input file to the utility.

  2. If the CTOCTI utility reports undefined tasks, do the following:

    1. Run the CTOCTA utility to determine which information is inaccurate or missing from the input file.

    2. Update the input file.

    3. Rerun the CTOCTI utility.

    4. Repeat these steps until the desired tasks are defined in the input file.

  3. When you are satisfied with the contents of the input file, do one of the following:

    • Change the attribute of object database COSIMGSD, located in member DAGLBLST, to DBINOUT. Reload the object database using the LOADGLOBAL command, described in the Control-O chapter of the INCONTROL for z/OS Administrator Guide.

    • Modify the CTO659I rule to point to a different object database that has an attribute of DBINOUT.

      • Rows reflecting the objects (resources) in your system are added to a specified object database in memory. Use the WRITEGLOBAL command to update the object database in the Control-O Variable Database files. For more information, see the Control-O chapter of the INCONTROL for z/OS Administrator Guide.

  4. Rerun the CTOCTI utility.

    • For more information about utilities CTOCTA and CTOCTI, see the INCONTROL for z/OS Utilities Guide. For more information about valid attributes for variable databases, see the Control-O chapter of the INCONTROL for z/OS Administrator Guide.

Implementing Control-O/COSMOS in a Production Environment

Control-O/COSMOS is implemented in a production environment after you have experimented with all aspects of Control-O/COSMOS in the demo environment and feel comfortable with the logic used to implement Control-O/COSMOS functions.

Use the following steps to implement Control-O/COSMOS in a production environment:

  1. Fill Control-O/COSMOS databases for the production environment. Skeleton database definitions (meaning databases with only columns defined) are provided with Control-O/COSMOS.

    • The demo databases provided with Control-O/COSMOS can be used as examples for the type of information that is inserted in the production databases.

    • The SYSIMAGE facility can be used to generate an object database describing objects in your production environment. Modify SYSIMAGE rule CTO659I to point to supplied production databases PRDSTCOB and PRDSTCSD.

    • For more information, see SYSIMAGE Facility – Automatic Generation of an Object Database.

  2. Change the following Global variable specifications in rule COSCLEAR:

    • Replace %%COSSTC = COSSTCOB with %%COSSTC = PRDSTCOB

    • Replace %%COSVTM = COSVTMOB with %%COSVTM = PRDVTMOB

    • This ensures that all Control-O/COSMOS-provided sample methods and rules use the production databases instead of the demonstration databases. (The provided rules obtain the database names from the AutoEdit variables when necessary.)

  3. Modify member COSMOLST so that it references Control-O/COSMOS production databases. Sample content for a production COSMOLST member is provided in member COSMOPRD in the Control-O PARM library. Rename this member to COSMOLST, or modify the existing COSMOLST member.

The first time Control-O/COSMOS is activated in a production environment, it is recommended that you first initialize all Control-O/COSMOS objects with a mode of FORCE_OK. This enables you to transfer control of specific objects to Control-O/COSMOS control one at a time, enabling you to more easily observe and customize the way Control-O/COSMOS handles objects at your site.

Production Databases Supplied With Control-O/COSMOS

The following production databases are provided:

Table 29 Production Databases

Database

Description

PRDALLPR Prerequisite database.
PRDALLMT Method database.
PRDSTCOB Working Object database for started task objects.
PRDVTMOB Working Object database for VTAM objects.
PRDSTCSD Source Object database for started task objects.
PRDVTMSD Source Object database for VTAM objects.

Adding a new object to Control-O/COSMOS

The initial definition of the started task (STC) objects handled by Control-O/COSMOS is described in SYSIMAGE Facility – Automatic Generation of an Object Database.

A new object can be added to Control-O/COSMOS after the initial generation of the object database by using Screen IV in ADMIN mode to manage a Source Object database (for example, COSIMGSD, COSSTCSD, or PRDSTCSD). See Screen IV: IOA Variable Database Facility.

To add a new object, perform the following steps:

  1. Enter Screen IV.

  2. Specify the DATABASE name and set MODE to ADMIN.

  3. On an existing row, type R (Repeat).

  4. On the duplicated row, type Z (Zoom).

  5. Change the values of the variables to the relevant values.

    • For the descriptions of the variables, see Table 13 in Source Object Databases.

  6. Use the PF3 key to exit the Zoom screen.

  7. Use the PF3 key again to exit Screen IV, and enter Y when asked whether you want to save changes.

The next time that Control-O/COSMOS is started, the new object will be copied to the corresponding object database (for example, COSIMGOB, COSSTCOB, or PRDSTCOB) and will be managed by Control-O/COSMOS.