Conversion Steps

This chapter includes the following topics:

Overview

This chapter describes the steps of the conversion process. A q marker indicates the beginning of each step. Read through this chapter before performing the steps. It is important to follow the sequence of the steps described below, to ensure a successful conversion.

The following summary checklist is provided for your convenience:

Table 4 Conversion Steps

Step

Description

1.

Conversion Tool component

2.

Identify Key Components of Your Current Console Automation

3.

Gather Detailed Information About Your Current Console Automation

4.

Prepare a Work Plan

5.

Convert Automation Scripts using Utility CTOFANCI

6.

Review Output of CTOFANCI and Perform Manual Conversion Tasks

7.

Implement Converted Rules in a Test Environment

8.

Implement Converted Rules in a Production Environment

Step 1. Control-O Conversion Tool components

The Control-O Conversion Tool is provided in the standard IOA installation libraries.

The Control-O Conversion Tool consists of three elements:

  1. CTOFANCI - found in IOA CLIST library

  2. CTOFJOB - sample JOB found in IOA SAMPLE library

  3. CTOFJPRM - sample parameters member found in IOA SAMPLE library

The Control-O Conversion Tool can be used as soon as IOA installation is complete, even if the installation of Control-O has not yet been performed.

Step 2. Identify Key Components of Your Current Console Automation

Gather the following information about console automation at your site:

  • Names and/or prefixes of libraries containing automation scripts.

  • Initialization parameters specified for your current console automation definitions.

  • Console automation requirements at your site (that is, what functions are currently handled by console automation tools, and what additional functions, if any, you want Control-O to handle).

Step 3. Gather Detailed Information About Your Current Console Automation

Run utility CTOFANCI in simulation mode to generate information about your current console automation definitions.

Specify the libraries containing your current console automation definitions as input for the utility.

The utility produces reports that provide detailed information about your console automation definitions and how they are converted to Control-O format.

The following reports are provided:

Table 5 Reports Produced by Utility CTOFANCI

Report

Description

RPTALL

General Message Report. Contains a copy of the control statements of the utility, and all messages generated by the utility.

RPTWARN

Warning Message Report. Contains all warning messages issued by the utility.

RPTFILES

Input/Output File Report. Contains information about all input and output files (datasets) used by the utility.

RPTRULES

Rule Report. Contains information about all input rules processed by the utility (for example, event type, rule size, and output member name).

RPTSRC

Rule Source Report. Contains all automation definition statements of input rules that were processed by the utility.

For a detailed description of utility CTOFANCI, see Utility CTOFANCI.

For more information about reports produced by utility CTOFANCI, see Reports.

Running the CTOFANCI Utility

Perform the following steps to run utility CTOFANCI at your site.

  1. Prepare the control statements of the utility.

    1. Edit member SYSINPRM (supplied with the Conversion Tool) or a copy of this member. This member contains the control statements for utility CTOFANCI. (For valid control statements and parameters that can be specified for the utility, see Utility CTOFANCI).

    2. Save the member.

  2. Prepare the conversion job.

    1. Edit member CTOFJOB (supplied with the Conversion Tool). This member contains a job that invokes REXX program CTOFANCI in TSO batch mode.

    2. Modify the SYSEXEC and SYSPROC DD statements to reference the library containing the CTOFANCI REXX execs.

    3. Modify the last line of member CTOFJOB so that it references a dataset and member name containing the control statements of utility CTOFANCI.

    4. Save the member CTOFJOB.

  3. Submit job CTOFJOB.

    4. For information about monitoring the execution of the utility see Troubleshooting.

    Multiple runs of utility CTOFANCI can be used to produce reports about different groups of input libraries and members and to adjust parameters to determine how they will affect conversion at your site.

Step 4. Prepare a Work Plan

Use the information collected in Steps 2 and 3 (above) to determine what will need to be done as part of the conversion process.

Consider the following issues when developing a work plan for conversion of console automation at your site to Control-O format:

  • Location of Input for the Conversion Tool

  • Input from Different Products

  • Members not Containing Automation Definitions

  • Similar and Duplicate Input Scripts

  • Complexity of Automation Definitions

Each of these issues is discussed in detail below.

Location of Input for the Conversion Tool

Your current console automation definitions may be located in any number of libraries. Some libraries may have some members that contain console automation definitions, and other members that do not contain such definitions.

The way in which automation definitions are organized at your site can influence the method you choose for converting them. Conversion Tool CTOFANCI can be used to convert automation definitions in one or more libraries in a single run. (for more information, see the following section.)

Input from Different Products

If several console automation products are in use at your site, you can convert the members containing automation definitions for multiple products at the same time, or for one product at a time.

  • If each product was used to implement automation of a different aspect of your environment, it is recommended that you convert the rules for each product separately.

  • If a certain type of automation has been implemented using more than one product at your site, it is recommended that you process all relevant libraries at the same time. This method can result in a more compact and more easily managed set of output rules.

The RPTRULES and RPTSRC reports generated by utility CTOFANCI can be sorted so that output rules are grouped by function (for example, all rules triggered by a specific message). This facilitates combination of automation rules from different products into Control-O rules that perform all the required functions.

Members not Containing Automation Definitions

Your automation libraries may contain members that do not contain automation scripts. These members may contain programs, CLISTs, REXX scripts, or JCL jobs that are part of your automation applications, or they may be related to other activities in your site.

You can identify these members and their locations using reports RPTRULES and RPTSRC, which are generated during a simulation run of the conversion utility CTOFANCI (performed in Step 3 above).

When utility CTOFANCI is run in normal mode, you can indicate names or a name pattern for output datasets and members to which members not containing automation definitions should be copied.

Similar and Duplicate Definitions

You can have more than one automation definition at your site that performs a given task. You can also have multiple definitions for similar tasks. Duplicate or similar definitions may have been defined for different systems, or they may be copies of a rule that are no longer in use. Sometimes, nearly identical rules perform the same function on different messages.

You should consolidate automatic conversion of similar automation definitions. During the manual adjustment phase of the conversion process you can delete unneeded duplicate Control-O rules that were created during the automatic phase of the conversion. Combining the conversion of similar automation definitions can result in more efficient Control-O implementation.

Report RPTRULES can be sorted according to various fields. The sorted report can be used to identify automation definitions that perform the same (or similar) tasks. The following attributes can be used to identify duplicate or similar input members:

  • Similar member names in different libraries.

  • Identical member size (total number of lines or number of member lines excluding comments).

  • Similar selection criteria (for example, rules that are triggered by the same message ID, or at the same time of day).

Complexity of Automation Definitions

Automation definitions can be very simple (for example, unconditional suppression of a specific message) or they can involve complex logic.

One way to identify complex automation definitions is by sorting the input scripts (rules) at your site according to length. Input script length is listed in reports RPTRULES and RPTSRC (for details, see Step 3. Gather Detailed Information About Your Current Console Automation).

Step 5. Convert Automation Scripts using Utility CTOFANCI

Run utility CTOFANCI in normal mode.

Utility CTOFANCI performs the automatic phase of conversion to Control-O. When run in normal mode, this utility processes your inventory of console automation definitions and performs the following tasks:

Table 6 Tasks Performed by Utility CTOFNACI in Normal Mode

Task

Description

Library and table creation

Utility CTOFANCI creates output libraries and Control-O Rule tables to contain output members and rules produced by the utility. Parameters of the utility specify the composition of the names of output libraries and Rule tables.

Rule creation

Utility CTOFANCI creates Control-O rule definitions that can be used to implement automation tasks similar to your current console automation definitions.

Inventory analysis

A series of reports are produced by each run of utility CTOFANCI. These reports can be used to analyze your current automation definitions.

Reports produced by utility CTOFANCI can also be used to determine how to modify utility parameters for additional runs of the utility. CTOFANCI reports are described in detail in 5 Reports.

Multiple runs of utility CTOFANCI can be used to process different groups of input libraries and members and to adjust parameters to suit your conversion needs.

For information about how to run utility CTOFANCI, see Step 3. Gather Detailed Information About Your Current Console Automation.

Step 6. Review Output of CTOFANCI and Perform Manual Conversion Tasks

The output of utility CTOFANCI (run in Step 4 above) consists of:

  • Control-O rules created from information in the input libraries.

  • Members that do not contain automation definitions and were copied from the input libraries to new locations.

  • Reports describing input and output of the utility. Certain reports are mentioned briefly below. These reports are described in detail in Reports.

Perform the following steps to review the output of utility CTOFANCI:

  1. Review the list of output rule libraries created or updated by utility CTOFANCI. This list is provided in report RPTFILES.

  2. Examine the Control-O rules created by utility CTOFANCI. (These rules are located in the rule libraries identified in the RPTFILES report.) The input script used to create each Control-O rule is included as comments in the rule. Review the input script (in the comments) and verify that statements converted automatically by the utility conform to your site’s requirements.

    3. Review statements of the input scripts not converted by the utility (in the comment lines of the output rules), and specify Control-O rule definition parameters that provide the required functionality.

    To help identify rules that must be modified, you can sort report RPTRULES by output dataset name, member name, and rule number to prepare an output rule verification checklist.

    You can extract report lines that contain a warning indicator to identify rules that require extra attention. You can assign rule verification tasks according to the completion indicator (<---, <<--, <<<-, or <<<<, where rules with an <<<< indication need only be visually verified while other rules may require more manual work).

    For more information about Control-O rule definition parameters, see the rule parameters chapter in the Control-O User Guide.

    If error message IOAE33E (Insufficient Storage) is displayed during an attempt to view a Rule table online, you can correct this problem by splitting the Rule table into multiple tables.

  3. Review report RPTWARN and make sure that each warning in this report has been handled. Possible responses to warnings in this report are:

    • No response, if the default handling performed by the utility satisfies your site’s functional requirements.

    • Modify the output rules (for example, using specification of additional rule definition parameters in the rules) to implement functionality described by input script statements, keywords, or parameters that were not translated by the utility.

  4. Rename output members that have duplicate names. Utility CTOFANCI assigns these members a prefix of @DUP (or an alternative prefix specified using utility parameter DUPPREF). The new names assigned to these members should conform to your site’s naming conventions.

    Certain duplicate members may not be needed. Unnecessary duplicate members can be deleted at this stage, or, if necessary, combined with other members to preserve desired functionality. (For more information, see Similar and Duplicate Definitions.)

Step 7. Implement Converted Rules in a Test Environment

Use the following steps to test the Control-O rules that you created in Steps 4 and 5:

  1. Install INCONTROL and Control-O in a test environment, where you can perform operations without adversely affecting production at your site.

  2. Specify the rule libraries created during conversion in the Rule Table list (member RULELIST) referenced by DD statement DARULLST in the Control-O monitor procedure.

  3. Activate Control-O.

  4. Generate events (for example, messages or commands) that should trigger Control-O rules. For example:

    • Generate messages and commands using utility IOATEST or CTOTEST.

    • Trigger time-driven rules by modifying the time of day in the system (this may require an IPL).

    • Submit jobs to trigger rules with selection criteria specifying job-related events (for example, job arrival, job ending, or job step completion).

  5. Verify that the Control-O rules handled simulated events in the desired way.

    • Watch the console for messages that should be issued or suppressed by the rules.

    • Watch TSO user IDs that should receive notification of events (that is, Shout messages).

    • Review the JES console log and the Control-O Automation log for additional messages that describe how events in the test environment were handled.

Step 8. Implement Converted Rules in a Production Environment

Use the following steps to implement Control-O rules created by the conversion process:

  1. Install INCONTROL and Control-O in your production environment.

  2. Specify the rule libraries created during conversion in the Rule Table list (member RULELIST) referenced by DD statement DARULLST in the Control-O monitor procedure.

  3. Activate Control-O.

The user can run specific Control-O rules in TEST mode to test the performance of the converted rules in the production environment.