Introduction

SolveWare Solutions are composed of the following major components:

• SolveWare solution documentation – This guide provides documentation for the SolveWare Solution Kit. It includes detailed descriptions of the automation solutions that are easy to understand and easy to implement.

• SolveWare message management solutions – The Control-O installation tape includes a library of predefined automation solutions that handle many of the most frequently occurring messages of MVS, VTAM, JES, CICS, and so on. At most sites, these solutions can be applied with little or no modification.

• SolveWare advanced automation solutions – The Control-O installation tape includes a library of predefined automation solutions that utilize KeyStroke OpenAccess (KOA) and NetView OpenAccess (NOA) scripts.

• Cross reference lists – A separate list is provided for each of the following: message, command, event and script names. Each message, command, event, or script name referenced by SolveWare is listed. This is followed by the SolveWare table in which the name and the relevant documentation page numbers are listed.

SolveWare Implementation Considerations

This section describes the steps involved in implementing SolveWare solutions.

Step 1. Studying Solveware Documentation and Definitions

The first step in implementing solutions is to examine the solution definitions that are provided in this guide to determine if each subject is relevant, or if the automation implementation concept is applicable, to your site.

Documentation Format

The SolveWare documentation is divided into the following parts:

• SolveWare subjects

  Groups of solutions organized by common problem category, such as CICS, DB2, or SUPPRESS. Each SolveWare subject is described in a separate chapter in this guide.

• Solutions

  Resolutions to specific problems. Solutions are made up of one or more rules and may also utilize KOA scripts, Control-M jobs, and so on.

• Rules

  Control-O rule definitions used to solve specific automation problems.

• KOA scripts

  KeyStroke OpenAccess scripts are invoked by rules. Transcripts interface with VTAM applications such as OMEGAMON to solve specific automation problems.

Each SolveWare subject provides one or more solutions and each solution consists of one or more rules.

Terminology

Rule documentation in this guide refers to the following rule classifications in Control-O:

• Scheduled rule

  Rule that was loaded into memory, automatically or manually.

• Active rule

  Rule for which all runtime scheduling criteria have been satisfied.

• In the Control-O Rule Status screen, an active rule has an ACTIVE status.

  Inactive rule

• Rule for which runtime scheduling criteria have not yet been satisfied.

  In the Control-O Rule Status screen, an inactive rule has a WAIT ACTIVATION status.

• Triggered rule

  A rule is triggered when its ON statement criteria have been satisfied (for example, the relevant command or message is issued). Event rules are triggered when they become active and can be triggered again cyclically.

Solution Definitions

The library and specific tables in which the rule is found are indicated in the documentation of the rule. Depending on whether the rule triggers jobs or KOA scripts, parts of solutions can be found in any of the appropriate Control-O SolveWare libraries:

Table 1 SolveWare Libraries

Library	Description
SOLVRULE	Sample Control-O rule tables.
SOLVJCL	Sample JCL members of Control-M jobs that are triggered by rules.
SOLVSCHD	Sample scheduling definitions for Control-M jobs that are triggered by rules.
SOLVKOA	Sample KOA scripts that are triggered by rules.

STARTSYS Rules

SolveWare rules provided with Control-O assume that certain Global variables (with specific values) and certain prerequisite conditions exist at your site.

To ensure that these variables and conditions exist and are compatible with SolveWare rule definitions, the rules included in SolveWare subject STARTSYS must be implemented.

Step 2. Customizing Rules Before Implementing

Rules may need to be tailored to the environment. Rule documentation contains customization considerations and instructions.

SolveWare Categories

The SolveWare category specified in the rule documentation provides an estimate of the amount of customization required. Rules are categorized according to the type of customization that the user must perform in order to adapt the rule to the environment.

SolveWare categories are:

Table 2 SolveWare Categories

Category	Description
Category 1	Minimal or no customization required.
Category 2	Some customization required.
Category 3	The rule is provided as an example that may or may not be applicable to the site. The amount of customization required is dependent upon site requirements.

Dynamic Destinations

SolveWare solutions send SHOUT messages to various destinations that are not necessarily fixed. Such destinations are known as dynamic destinations and are maintained in the IOA Dynamic Destination table. This table enables the user to specify a group name destination and the final multiple destinations it represents.

SHOUT destinations that are defined in the IOA Dynamic Destination table can be updated in the table instead of updating the SHOUT destinations individually in the rule definitions.

SolveWare SHOUT messages are sent to the following dynamic destinations:

Table 3 Destinations for SHOUT Messages

Message	Description
U-IOADMIN	INCONTROL administrator
U-SYSADMIN	System administrator
U-SYSCICS	CICS administrator
U-SHFTOPER	Shift operator
U-SYSDBA	Database administrator

OWNER Parameter

Parameter OWNER is often used to determine whether a rule has authorization for requested actions. Customize this parameter according to your on-site security standards so that SolveWare rules are granted required authorization.

Inverse IN Conditions

Many SolveWare solutions use the Control-O inverse IN condition feature to deactivate rules. The use of inverse IN conditions greatly simplifies rule deactivation.

Inverse IN conditions are indicated by a "Not" symbol (Ø or !) prefixed to the condition. For example: !CTO-IFB060E-HANDLED

A rule defined with an inverse IN condition is inactive when its IN condition does exist and active when its IN condition does not exist. For more details, see the rule parameters chapter of the Control-O User Guide.

It is also possible to use a standard (non-inverse) prerequisite IN condition to deactivate rules. Such a rule is inactive when its IN condition does not exist and active when its IN condition does exist. However, before implementing such a rule, the required IN condition must be added manually in order to activate the rule for the first time.

For this reason, SolveWare solutions use inverse IN conditions that do not require adding the condition manually before implementing the rule.

Rule Thresholds

The term "threshold" refers to the maximum number of times a message can appear within a specified number of minutes. The threshold parameters for each message can be adapted to site requirements.

Following are some instances where you should specify a threshold.

Step 3. Testing and Implementing Rules

Test all SolveWare rules before they are implemented. The recommended method for testing rules is to trigger a rule operating in TEST or LOG mode using utility IOATEST (detailed below). Next, review the test journal (log) of the rule’s events and actions. After all events and actions are satisfactory, the rule can be scheduled for execution in the production mode.Operation Modes

The Recommended Mode in the rule documentation refers to the mode for initial testing and/or operating. The following table describes the operation modes.

Table 4 Operation Modes

Mode	Description
TEST	Console actions are not performed; they are written to a test journal. Setting of Global variables is performed.
LOG	The rule is processed normally (as in PROD mode) and, in addition, all identified events and actions are written to a test journal.
PROD	Production mode. The rule is processed normally.

Problem Simulation

In order to test rules, rules must be triggered utility IOATEST can be used to issue messages to the console subsystem, thus simulating the problem situation and triggering the relevant rules.

For example, message IEF281I ddd NOW OFFLINE can be sent to the console subsystem using utility IOATEST without actually varying the device off-line. The relevant rule is triggered by this message and its results can then be examined.

For license and warranty information, refer to member $$RULES in the -O Installation library.