Introduction

This chapter contains the following topics:

• INCONTROL Products and IOA

  • IOA

  • INCONTROL

• Functional Approach

  • Main Components

  • Expanded Control-O Functionality

  • Online User Interface

• Control-O Concepts

  • IOA Core and the Control-O Repository

• Date Definition Concepts

  • System Date

  • Working Date

  • Date Standards and Date Field Formats

  • Prerequisite Condition Concepts

  • Rule Ordering, Activation, and Triggering

INCONTROL Products and IOA

The Control-O Console Automation System is a component member of the INCONTROL by BMC suite of products, a fully integrated suite designed to automate, manage and streamline operations on the z/OS mainframe and other platforms. The INCONTROL family of products also includes client/server products that facilitate the automation of other platforms.

IOA

The Integrated Operations Architecture (IOA) is at the heart of the INCONTROL family of products. IOA has a common core of shared code as the foundation of its architecture design. INCONTROL's IOA environment has several inherent design advantages, including a common user interface and a shared data repository. A key feature of the IOA environment is its integrated application design, which includes:

• Integrated User Notification

• Management by Exception

• Integrated Scheduling

• Interdependency and Interrelationship Handling

• Common Help Facility

• Integrated Management Reporting

• Common Method for Sharing Information

• Unified Installation and Maintenance

• Unified Security Implementation

• Open Interface Design

INCONTROL

The INCONTROL family of products includes those shown in Table 1:

Table 1 List of INCONTROL Products

Product	Description
Control-M	Automated Production Control and Scheduling System Manages and automates the setup, scheduling and execution of jobs in the data center.
Control-M/Restart	Restart Management System Automates the activities that must be performed when restarting failed jobs, including the scratching and uncataloging of data sets created by failed jobs.
Control-M/Tape	Removable Media Management System Increases utilization of removable media and controls retention periods. Prevents misuse of media, and provides tape library and vault control.
Control-M/Analyzer	Automated Information Integrity System Performs in-stream validation, accuracy, and reasonability checks on information used by data center production tasks (for example, reports, databases).
Control-D	Output Management System Automatically schedules and controls every aspect of report processing and distribution, including report decollating, bundling, printing, online viewing, and archiving.
Control-V	Quick Access Archive Viewing System Provides online access to archived reports and documents by indexed data retrieval.
Control-D/ Page On Demand	Report Retrieval and Display System Enables end users to retrieve and view pages of reports that reside on mainframe storage in real time. Indexed reports can be retrieved by index name and value. AFP and XEROX reports can also be retrieved and displayed using Control-D/Web Access Server or Control-D/Page On Demand API.
Control-D/ Image	Image Output Management System Enables output from commercial imaging equipment to be imported into either Control-D or Control-V for decollation, distribution and viewing, and into Control-V for archiving and indexed retrieval.
Control-O	Console Automation System and Desired State Monitoring System Monitors and automatically responds to messages, commands, and data set events, as well as various other system events. The Control-O/COSMOS feature allows for status monitoring while maintaining all critical system objects in a desired and ideal status.

Functional Approach

Control-O automatically detects messages, commands, and events, and responds by performing console actions according to predefined user specifications.

• Some examples of message, command, and event criteria that can be used to trigger a response from Control-O are

  • a specific message containing a specific string

  • an action threshold

  • a day, time, or date

  • a message issued by a specific job

  • a data set event

  • OMEGAMON exception event

• Some of the actions Control-O can perform in response to detected messages, commands and events are

  • suppress a message

  • reply to a WTOR message

  • modify the text of a message

  • reroute a message

  • change the descriptor code of a message

  • issue an operator command

  • initiate a job or a started task

  • notify the user of a system event

  • perform a TSO command

  • perform a KeyStroke OpenAccess script to automate VTAM applications
    KeyStroke OpenAccess scripts are described in KOA Recording

Control-O has many facilities and components. Working together, they serve to automate the data center. This chapter introduces Control-O facilities and components from a functional perspective, beginning with the major components that comprise the heart of Control-O and progressing to the less central components which enhance the functionality of Control-O.

Main Components

The main components essential to Control-O are

• Control-O rule definitions

• Control-O monitor

Control-O Rule Definitions

A Control-O rule is a set of parameters that define actions to be performed upon the detection of specified message, command and event criteria. When message, command and event criteria are detected, the rule is triggered (that is, the actions specified in the rule are performed).

Each rule definition contains the sections shown in Table 2:

Table 2 Rule Definition Sections

Section	Description
Message/Event Selection Criteria	The message, command, or event that, when detected, triggers the rule.
General Parameters	General information about the rule, such as its description and security mode.
Action Parameters	Actions to be performed when the rule is triggered.
Basic Scheduling Parameters	Days and dates on which a Control-O rule is eligible for triggering.
Runtime Scheduling Parameters	Conditions that must exist before a Control-O rule is eligible for triggering.

Each rule only needs to be defined once. (The mechanism used to define Control-O rules is discussed later in this chapter.) Once defined, the rule definition is saved. It can be modified later on as required, and the changes saved.

Rule definitions are stored in members in partitioned data sets (libraries) as follows:

• Multiple rule libraries can be defined.

• Multiple rule tables are stored together in partitioned data sets called rule libraries.

• Rule definitions for related topics (for example, IPL or CICS) are generally stored together in a single member called a "rule table."

The Control-O Monitor

The Control-O monitor is a started task that handles rule processing. It detects messages, commands and events in the z/OS environment, and triggers rules accordingly.

• It operates continuously 24 hours a day. It constantly scans the environment for messages, commands, and events that trigger predefined actions, that is, Control-O rules.

• It interacts with the Control-O subsystem to manage all Control-O activity, and performs housekeeping tasks at regular intervals.

Expanded Control-O Functionality

Having explained the main components of Control-O, we can now build upon this foundation and describe a number of the facilities and components that enhance the Control-O functionality.

Automated Loading of Rules

Control-O rules are normally loaded when Control-O is activated. A predefined list of rule tables is scanned for rules that should be activated for the current day or date. Rules with day or date specifications, meaning their basic scheduling criteria, that are met, are loaded into memory.

Control-O rules should be automatically reloaded each day through the Daily rule. A Daily rule orders a list of rule tables each day at a specified time. A sample Daily rule (DAILY) is supplied in the Control-O Rules library.

Message Manipulation

One of the primary functions of Control-O is message manipulation. Messages sent to the console can be suppressed, forwarded, translated, and so on, depending on the actions specified in Control-O rules. A message can also be used to trigger other actions, such as forcing a Control-M job, or issuing an z/OS command.

Control-O can also send WTO and WTOR messages:

• WTO messages are sent through the Shout facility, described immediately below.

• WTOR messages are sent through a DO ASKOPER statement, described in DO ASKOPER: Automated Console Action Parameter.

Operator Notification (Shout Facility)

Control-O can send messages (known as Shout messages) to specified locations in response to detected messages, commands, or events. For each Shout message to be sent, the user defines the message, the degree of urgency, and the location to which the message should be sent.

For more information on the Shout facility, see DO SHOUT: Automated Console Action Parameter

Monitoring of Conditions

Control-O constantly scans a list of user-defined conditions called the IOA Conditions file. Conditions in this file can be set by Control-O or any other INCONTROL product at your site. A rule is triggered by the detection of conditions (specified in the runtime criteria of the rule) that did not previously exist, or the absence of a condition that previously existed.

AutoEdit Facility

The AutoEdit facility enables inclusion of user-defined variables and system variables in rule definitions. AutoEdit variables are generally specified in place of hard coded values which change frequently, such as the current date. The variables are resolved (that is, they are replaced with the appropriate values) during rule processing. The use of AutoEdit variables can eliminate the need to edit and update rules once they have been defined.

User-defined variables that are defined as Global variables can be used by other Control-O rules triggered on the same system.

User-defined variables that are defined as Sysplex-wide variables can be used by other Control-O rules triggered anywhere in the Sysplex.

For added flexibility, various AutoEdit functions and control statements can be used to manipulate variables and constants anywhere AutoEdit expressions are used.

For more information on the AutoEdit facility, see AutoEdit Facility.

IOA Variable Database Facility

The IOA Variable Database Facility enables creation and modification of AutoEdit Variable databases. These databases are used to hold Global AutoEdit variables, which can be created, accessed and updated by Control-O rules and KOA scripts. When Sysplex support (the XAE Facility) is installed, these variable databases can be accessed by different instances of Control-O across the Sysplex.

The IOA Variable Database Facility is accessed online by means of Option IV of the IOA Primary Option Menu.

KeyStroke Languages

KeyStroke languages are languages that can be used to simulate, in batch, the keystrokes of the user. The types of KeyStroke languages that can be used with Control-O are shown below.

KeyStroke Language	Description
KSL	A general purpose language which simulates, in batch, keystrokes entered in the IOA Online facility. KSL language statements are specified in "programs" called scripts. KSL scripts can be used to automate routine tasks, and to generate reports based on IOA and product-specific repository files.
KOA	An extension of KSL. KOA (Keystroke Open Access) includes all KSL commands and functions as well as additional commands used for interfacing with VTAM applications. With KOA, the user can automate 2-way communication with any VTAM application, such as performance monitors or NetView.

For more information on KeyStroke Language, refer to the KeyStroke Language (KSL) User Guide.

Accumulating Statistics

Control-O accumulates statistics about rule processing, through the Message Statistics facility. The Message Statistics facility records all messages and commands detected by Control-O, and allows them to be sorted and selected based on various criteria.

By studying information provided by the Message Statistics facility, you can evaluate console automation at your site and what can be done to improve it. For example, if you determine that certain messages are issued frequently but are not responded to by Control-O, you may want to define Control-O rules that will handle, or suppress, those messages automatically and in this way, save the operator valuable time.

For more information, see Message Statistics Screen.

Controlling Availability of Resources (Objects)

Control-O/COSMOS is an integral feature of Control-O. Control-O/COSMOS manages the status of objects in the computing environment, such as started tasks and terminals. Control-O/COSMOS periodically checks each object in the computing environment and determines if its current status is the desired status. If necessary, Control-O/COSMOS takes steps to ensure that the desired status is established.

Control-O/COSMOS also simplifies the automation of your system startup and shutdown.

Various online screens enable manipulation of objects controlled by Control-O/COSMOS.

For more information on Control-O/COSMOS, see the Control-O/COSMOS User Guide.

IOA Log Facility

Messages issued by Control-O are written in the IOA Log file. The IOA Log file is a repository of messages issued by all INCONTROL products. Through the IOA Log facility, the user can examine messages issued by Control-O during rule processing.

Operation Modes

Control-O rules can be run in the operation modes shown in Table 3.

Table 3 Control-O Operation Modes

Mode	Description
Production mode	All specified actions within a rule are performed, but are not recorded in the Control-O Automation Log.
Test mode	Console actions are not performed, but are recorded in the Control-O Automation Log. Global variables are updated.
Log mode	All specified actions within a rule are performed (as in production mode) and intercepted events and actions are recorded in the Control-O Automation Log.

Modes can be specified globally for all Control-O operations or for specific rules. For more information, see MODE: General Parameter, and the Control-O LOG operator command in the Control-O chapter of the INCONTROL for z/OS Administrator Guide.

Utilities

Utilities provided with Control-O are used to perform a variety of management functions and generate reports that assist in the efficient use of Control-O. These utilities are described in the INCONTROL for z/OS Utilities Guide.

Rule Scheduling Through Calendars: IOA Calendar Facility

You can simplify the specification of scheduling criteria for rules by using calendar definitions. A calendar definition consists of a defined schedule (for example, Mondays through Fridays in each week in each month) which can be applied to rules.

Calendars are defined in the IOA Calendar facility. Each calendar is assigned a unique name, which can be specified in rule definitions. A particular calendar, or schedule, only needs to be defined once.

Specification of the name of a calendar in rule definitions causes that calendar to be used to schedule those rules.

Two types of calendars can be defined:

• Regular

• Periodic

Regular calendars contain schedules that can be easily defined using Basic Scheduling parameters. These calendars consist of scheduling dates or days (of the week) which can be fixed according to monthly patterns.

Automation in Different Environments

Control-O can interact with the various products in use at your site to provide a wide variety of solutions to common problems and to automate many routine tasks at your site. Some components with which Control-O interacts are

• CICS Automation

• JES2 and JES3

• IMS

• Control-O Extended Automation Mechanism (XAM)

• OMEGAMON products

• SMS

• job SYSOUT processing

CICS Automation

Control-O can automate the operation of CICS, controlling multiple CICS regions from one terminal. About 50% of all CICS messages are routed to CICS transient queues and not to the MVS console. These messages can be automated in the same way as messages routed to MVS consoles.

Control-O CICS automation can

• manage all CICS messages

• manage the availability, serviceability, and recoverability of CICS

• start and stop CICS regions and change startup parameters

• inform Control-M of CICS status

• instruct Control-M to submit a job that processes a file that was closed under CICS

JES2 and JES3

Control-O can automate JES2 and JES3 operations. JES2 and JES3 messages and commands are automated in the same way as messages and commands routed to MVS consoles.

IMS

Control-O can automate the operation of IMS. Messages routed to the IMS Master terminal can be managed in the same way as messages routed to MVS consoles.

The automation of IMS by Control-O can

• manage IMS error and warning messages

• manage the availability, serviceability and recoverability of IMS

• start and stop IMS/DC, and change startup parameters

• inform Control-M of IMS/DC status

• trigger Control-M to submit an IMS recovery job

• receive performance data through a KOA Script, and act accordingly

SMS

SMS includes definitions referenced by the SMS ACS routines. When SMS is implemented, any change to a definition may affect any or all of the Control-O rules at your site. To prevent this, the SMS administrator can configure Control-O rules to override SMS ACS routines, thereby forcing storage methods as defined by Control-O.

The SMS administrator can create and test SMS definitions without influencing other SMS definitions. To determine the behavior of SMS definitions, Control-O users can inspect the trace of the SMS rules in the Automation Log.

In addition, Control-O can add automation to SMS processing that is not available through SMS ACS routines.

Job SYSOUT Processing

Many applications write messages to a Job SYSOUT data set and use it as their internal log. Control-O can intercept messages that are written to Job SYSOUT data sets.

Control-O Extended Automation Mechanism

The XAM (Extended Automation Mechanism) interface of Control-O enables you to share information between an external environment and Control-O, using CLIST, REXX, user-written programs, and so on. The XAM interface can also be used to issue requests that trigger Control-O actions. Actions that can be requested are

• AutoEdit Expression Resolution

• AutoEdit Local Variable Setting

• AutoEdit Global Variable Setting

• Control-O Rule Triggering

For more information, see Extended Automation Mechanism.

Communication with Other Systems

Control-O can issue messages and commands on other systems, and it can respond to messages and commands from other systems.

Particular responses to messages can be made dependent on which system or console issued the message.

Control-O directs actions to be performed on other systems through the SYSTEM subparameter or by the %%$COMMSYS system variable in DO COMMAND, DO COND, DO DISPLAY, DO FORCEJOB, DO RESOURCE, DO RULE, DO SHOUT and DO CTD REQ statements.

• If the systems are members of a Sysplex environment, Control-O routes action requests to the specified member of the Sysplex environment, using the extended MCS console for DO COMMAND and DO DISPLAY, and XCF services for DO RULE.

• If the systems are connected through VTAM or TCP, Control-O uses the IOA gateway to transfer action requests to the specified system, and waits for the response if necessary, for example, if WAITRESP=Y is specified in a DO COMMAND statement.

MAINVIEW® Alarm Manager

The MAINVIEW Alarm Manager inspects data collected by the MAINVIEW line of monitors for values indicating a potential performance problem. It then issues a warning or informs the user about the problem, as specified in the alarm definition.

For more information, see ON MVALARM: Message/Event Selection Parameter.

Online User Interface

Until now we have seen how Control-O automates console management and we have discussed a number of the available facilities which enhance the functionality of Control-O.

However, as mentioned earlier, Control-O provides an online user interface which enables the user to

• interface with most of the previously described facilities

• intervene in the processes of console management

• immediately access up-to-date information on console automation processing

The online user interface is provided through online facilities that are accessed through the IOA Primary Option menu.

Certain online facilities are unique to Control-O, and other facilities are shared by many or all INCONTROL products.

All IOA and Control-O Online facilities are described in detail in Online Facilities. They are outlined briefly on the following pages.

Rule Definition Facility

The Control-O Rule Definition facility is accessed through Option OR of the Primary Option menu. It is the main online facility for creating, defining, modifying, and deleting the following:

• rule libraries

• rule tables

• rule definitions

In addition, this facility can be used to

• edit a rule definition

• manually order or force a rule or rule table

• Ordering activates a rule only if its basic scheduling criteria are met. Forcing activates a rule regardless of its basic scheduling criteria.

Rule Status Screen

The Rule Status screen is accessed through Option OS of the IOA Primary Option menu. It displays all rules currently loaded into memory and their statuses. The various fields in this screen provide information on

• whether or not the rule is currently being processed

• the number of times the rule has been triggered

• the rule type

• the rule location (that is, the member and library containing the rule definition)

• the mode, owner, and runtime security of the rule

A show option window can be used to limit the information displayed in this screen, according to the contents of the various fields for each rule.

Message Statistics Facility

The Message Statistics facility is accessed through Option OM of the IOA Primary Option menu. It accumulates statistical information on messages and commands issued in the system. This information is stored in a data set which is created during Control-O installation and which is unique to each Control-O system.

Automation Log

Automation information is stored in the Automation Log, which is accessed through Option OL in the IOA Primary Option menu.

The Automation Log facility accumulates and displays automation information from all input available to Control-O, including console, IMS, CICS messages, Control-O events, Control-O internal messages, application internal logs, and rule traces.

Comprehensive SHOW selection criteria allow the user to query the log for analysis and statistical purposes. This analysis and statistical information is especially useful when planning, implementing and checking console automation.

Users may also choose to switch between viewing the current log, archived logs, or logs of other systems within a shared DASD environment, without interfering with the ongoing accumulation and display of messages within any of these logs.

In a Sysplex environment, viewing of the OPERLOG can be synchronized with the viewing of the Automation Log.

Automation Options

Automation Options are a set of operator productivity tools that can be activated online. A menu of Automation Options is accessed through option OA in the IOA Primary Option menu. The Automation Options shown in Table 4 are provided with Control-O.

Table 4 Control-O Automation Options

Option	Description
COMMAND	Allows operator commands to be entered, and displays the command responses.
CONSOLES	Displays the contents of active MCS consoles according to a specified console ID or name. The Console Display screen is a replica of the specified console.
ENQ	Displays enqueue information, which is information about jobs that hold resources, and jobs that are waiting for resources. This option facilitates the tracking of resource contention problems between jobs so that when conflicts are resolved, overall efficiency of the site is improved.
GLOBALS	Displays Control-O Global variables and their values according to specified selection criteria.
OPERATOR	Displays a submenu of preset operator commands. Upon selection, commands are entered and the responses are displayed.
SAMPLES	Sample implementations of Automation Options.
SERVERS	Allows online tracking and control of Control-O servers. Servers increase the efficiency and enhance the performance of TSO, KOA, and SHELL requests by eliminating the need to set up an environment for execution of each TSO, KOA, or SHELL request.
SUBSYS	Displays a list of the MVS subsystems, their statuses, and their active functions.

KOA Recorder Facility

The KOA Recorder facility records manually performed keystrokes and automatically generates a KOA script. Generation of a KOA script using this facility is much easier than writing the KOA script in a file.

Control-O/COSMOS Status Monitoring System

The Control-O/COSMOS Status Monitoring System is a feature of Control-O, offering monitoring of objects within the system and maintaining them in specified desired statuses. Control-O/COSMOS is accessed through Option OC of the IOA Primary Option menu. For more information, see the Control-O/COSMOS User Guide.

IOA Conditions/Resources Screen

The IOA Conditions/Resources screen is accessed through Option 4 of the IOA Primary Option menu. It displays information from the IOA Conditions file, which contains the list of all existing prerequisite conditions, and the Control-M Resources file, which contains the list of Quantitative resources and Control resources. The IOA Conditions/Resources screen enables the user to

• view IOA prerequisite conditions

• view Control-M Quantitative resources

• add or delete prerequisite conditions or resources

• change the available quantity of Quantitative resources

IOA Log Screen

IOA messages are written to the IOA Log file. Messages can be viewed using Option 5 in the IOA Primary Option menu. These messages record every significant event in the life of jobs, started tasks, missions, rules, and similar entities under the control of INCONTROL products. This includes messages generated for normal processing and any error conditions encountered during processing. The IOA Log file also contains messages directed to the IOA Log from the Shout facility.

The IOA Log file stores a limited number of messages, as specified by means of an installation parameter. Each new entry in the IOA Log file overwrites the oldest existing entry. The user can filter IOA Log file contents displayed in the IOA Log screen, using a Show Screen filter window that allows specification of viewing criteria for each field in the IOA Log screen.

IOA Calendar Facility

The IOA Calendar facility is accessed through Option 8 of the IOA Primary Option menu. IOA calendars allow definition of common scheduling patterns that then simplify the specification of basic scheduling criteria in rule definitions. The IOA Calendar facility enables the user to create, define, modify, and delete IOA calendars.

Control-O Concepts

Having discussed Control-O from a functional viewpoint, and having briefly outlined the online user interface to Control-O, it is now worthwhile to discuss certain important concepts in Control-O functioning.

IOA Core and the Control-O Repository

A differentiation is made between files belonging to a particular product such as Control-O, and IOA files that are shared among INCONTROL products. Shared IOA files are collectively referred to as the IOA Core. The IOA Core consists of the files shown in Table 5.

Table 5 IOA Core Files

File	Description
IOA Log File	File in which all messages issued by INCONTROL products are recorded.
IOA Conditions File	File listing available conditions identified and tracked by the Control-O monitor.
IOA Manual Conditions File	File listing prerequisite conditions that must be added manually. These are prerequisite conditions required by Control-M jobs or Control-D missions, and which are not automatically added by other jobs or missions in the Active Jobs or Missions files.
IOA Calendar Tables	Files containing IOA calendar definitions.
Dynamic Destination Table	File containing a list of destinations for messages issued by the IOA Shout facility.
Mail Destination Table	File containing a list of mail destinations for messages issued by the IOA Shout facility.
SNMP Destination Table	File containing a list of SNMP destinations for messages issued by DO SNMP action.

Files belonging to a particular product are called the "repository" of that product. The Control-O repository consists of the files shown in Table 6.

Table 6 Control-O Repository Files

File	Description
Rule Tables	Tables containing Control-O rule definitions.
Message Statistics File	List of all messages and commands detected in the system, and various information about each message, such as frequency, and whether it was suppressed.
Automation Log	Automation information about all input available to Control-O. This includes the following: messages and commands of the console, IMS, CICS, and internal logs of monitored applications Control-O internal messages Control-O rule traces
Global AutoEdit Library	A list of user-defined Global variables. The members of this library are loaded when Control-O is started, and they can be updated or reloaded using various operator commands. For more information about Global variables, see Global Variables and the Control-O chapter of the INCONTROL for z/OS Administrator Guide.
AutoEdit Variable Database Files	A set of three IOA Access Method files containing all information about existing AutoEdit Variable databases. Variable databases are loaded when Control-O is started and can be updated or reloaded using various operator commands.

Variable databases can also be modified through the Online Variable Database Definition facility (Screen IV), which is described in IOA Variables Database Facility.

Date Definition Concepts

The following types of date definitions are recognized by Control-O:

• system date

• working date

System Date

The date as supplied by the operating system. This date should reflect the actual calendar date that starts and ends at midnight.

Working Date

Many sites do not use midnight as the formal time for changing to a new date. For example, a site may determine that all processing performed between the hours of midnight and 6:00 a.m. belongs to the previous day. In this case, the installation working date at the site changes at 6:00 a.m., not at midnight.

The working date, which is the time at which the date changes at the site, is defined in the Control-O installation parameters. The Daily rules are generally triggered at the beginning of the working day.

Date Standards and Date Field Formats

Date standards and date field formats use either Gregorian or Julian dates.

Gregorian Dates

Gregorian dates are indicated in this guide by the symbols shown in Table 7.

Table 7 Gregorian Date Notation

Symbol	Description
dd	Day of the month (from 01 through 31)
mm	Month (from 01 through 12)
yy	Year. Last two digits of the year. If the last two digits in the specified year are a number less than 56, INCONTROL presumes that the year is in the 21st century. For example, if yy=15, the year 2015 would be presumed. Otherwise, INCONTROL presumes that the year is in the 20th century. For example, if yy=80, the year 1980 would be presumed.
yyyy	Year. 4-digit year

Whether a field holds a 4-character date (month and day), a 6-character date (month, day and 2-digit year) or an 8-character date (month, day and 4-digit year) depends on the field. However, the format of the 4-character, 6-character or 8-character date depends on the installation-defined date standard.

INCONTROL products support three date standards for Gregorian dates. Each standard has a 4-character format, a 6-character format, and an 8-character format. Only one Gregorian date standard is defined at any site.

These supported Gregorian date standards are described in Table 8.

Table 8 Supported Gregorian Dates

Standard	4-Character Date	6-Character Date	8-Character Date
MDY	mmdd	mmddyy	mmddyyyy
DMY	ddmm	ddmmyy	ddmmyyyy
YMD	mmdd	yymmdd	yyyymmdd

Julian Dates

Julian dates (also supported by INCONTROL products) are indicated in this guide by the symbols shown in Table 9.

Table 9 Julian Date Notation

Symbol	Description
jjj or ddd	Day of the year (001 - 365 or 366, as appropriate for the year)
yy	Last two digits of the year
yyyy	Four digits of the year

Julian date fields have either three, five, or seven characters. Whether a Julian date field holds a 3-character date (day of year only), 5-character date (day of year and 2-digit year) or a 7-character date (day of year and 4-digit year) depends on the field definition. However, the format of the date depends on the installation-defined date standard.

For example, the Julian date for the calendar date of 28 February 2000 would be represented in jjj or ddd format as 059, in yyjjj or yyddd format as 00059, and in yyyyjjj or yyyyddd format as 2000059.

Prerequisite Condition Concepts

The prerequisite condition concept is one of the key concepts of Control-O processing.

A prerequisite condition is a user-defined descriptive name given to a certain situation or condition. Prerequisite conditions can be specified in either of the following types of statements in a Control-O rule definition.

Table 10 Prerequisite Condition Statements

Statement	Description
DO COND statements	Used to set or clear a prerequisite condition.
IN statements	A Runtime Scheduling parameter used to make the triggering of a rule dependent on the existence or nonexistence of a specified prerequisite condition.

Prerequisite conditions enable the establishment of rule dependencies. They can also serve as a method of communication between Control-O and the other INCONTROL products at your site.

Control-O uses prerequisite conditions to track the statuses of various aspects of the environment. When the status of a specific aspect of the environment changes, a Control-O rule can set or delete a condition to indicate this and subsequently trigger rules whose execution is dependent on the status of this condition.

Additional Aspects of Prerequisite Condition Functioning

Prerequisite conditions are entirely under user control. Rule dependencies do not have to be as simple as the above example illustrates. An almost unlimited number of conditions and rule dependencies can be created.

• Rule execution can be dependent on more than one prerequisite condition.

• Rules can add and/or delete more than one prerequisite condition.

• The same prerequisite condition can be added by more than one rule (caution should be used).

• The same prerequisite condition can be used as an IN condition for more than one rule.

Prerequisite Condition Dates

IN statements and DO COND statements each provide a field used to specify a date for each prerequisite condition. A DO COND prerequisite condition which is added with a particular date cannot satisfy an IN statement in which this prerequisite condition is specified with a different date.

Rule Ordering, Activation, and Triggering

Control-O rule utilization consists of three phases. Control-O rules are ordered, activated, and triggered as described below.

When Control-O is brought up, rules in tables specified in the Control-O procedure are automatically ordered depending on their basic scheduling criteria. Rule tables can be also manually ordered or forced at any time through the Table List screen or an operator command. The ordering or forcing of rules places them in the memory of the Control-O monitor.

Ordered or forced rules are now eligible for activation. Control-O monitors the IOA environment and activates rules when their runtime scheduling criteria are satisfied. Runtime scheduling criteria can, for example, make rule activation dependent upon specific prerequisite conditions, or they can limit the activation of the rule to a specific time period. For more information, see Runtime Scheduling Parameters, and Runtime Scheduling Parameters – Summary.

Activated rules are eligible for triggering. A rule is triggered by an occurrence of the message, command or event specified in the ON statements in the rule. When a rule is triggered, the actions defined in the rule are performed. For more information, see ON Statement: Message/Event Selection Parameter.