IOA Concepts and Components

Overview

Integrated Operations Architecture (IOA) is the keystone of a fully integrated family of products (INCONTROL products) designed to help you streamline and automate your mainframe operations.

IOA provides you with the capability of implementing unattended, "lights out" operations.

INCONTROL Products and IOA

The INCONTROL family of products shares a set of common components and concepts. This chapter contains an introduction to the INCONTROL products and the basic concepts and components used in IOA processing.

IOA

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:

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 JCL Verify

Site Standards Enforcement and JCL Validation System

Validates JCL jobs, ensures site standards, and issues validation reports. While Control-M JCL Verify is closely integrated with Control-M for z/OS, it can be installed as a standalone product on sites that are not using Control-M.

Control‑M/Restart

Restart Management System
Automates the activities that must be performed when restarting failed jobs, including the scratching and uncataloging of datasets 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/WebAccess 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 dataset 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.        

A number of common components are shared by INCONTROL products. Furthermore, various INCONTROL products use similar operating procedures. The remainder of this chapter contains a brief description of components and features common to INCONTROL products, followed by references indicating where more detailed information can be found.

Installation and Maintenance

Installation of INCONTROL products is performed using an ISPF menu‑driven interface, the INCONTROL Installation and Customization Engine (ICE).

Maintenance is performed using SMP/E.

Installation and Customization Engine

ICE is an ISPF application used to install and customize INCONTROL products. It consists of a series of dialog screens that provide a simple method to enter data and to create and submit installation jobs.

Tasks in ICE are organized in a hierarchical manner.

ICE displays the IOA installation online activities in the INCONTROL Installation Options screen. Each menu option represents a key activity related to installing and maintaining IOA.

Each activity is organized as a list of major steps. Each major step consists of one or more minor steps.

Each minor step allows the user to specify parameters, submit jobs, or perform other tasks related to the installation process.

For a detailed description of the ICE application, see the INCONTROL for z/OS Installation Guide: Installing.

Product Maintenance

Product maintenance is the process by which updates are implemented between versions. These updates may consist of improvements to the software or resolutions to problems that were discovered during day-to-day product use. These updates are implemented using SMP/E only.

Product maintenance falls into two categories:

  • Periodic maintenance, sometimes called preventative maintenance, consists of software updates (PTFs) that are collected, tested and distributed as a package on a periodic basis. The maintenance level of an installation is defined by the highest level of periodic maintenance applied.

  • Ad hoc maintenance, sometimes called corrective maintenance, consists of one or more PTFs that are applied as necessary, according to specific customer needs.

For a detailed description of maintenance implementation, see the INCONTROL for z/OS Installation Guide: Upgrading.

Online Facility

The IOA Online facility (IOAOMON) is a set of interactive applications that facilitate communication with IOA. The IOA Online facility generates all IOA screens and handles all IOA online functions.

The IOA Online facility can be accessed directly under TSO, ISPF, TSO/ISPF and ROSCOE. In addition, the IOA Online facility can be accessed using CICS, IMS, IDMS, VTAM, ROSCOE, TSO or COM‑PLETE under the IOA Online monitor.

When a user enters the IOA Online environment using a communication monitor or TSO/ISPF, the IOA Primary Option menu is displayed. This menu lists the options available to the user.

For a description of the IOA Online facility, see IOA Administration.

IOA Primary Option Menu

The IOA Primary Option menu displays INCONTROL product options and facilities available to the user.

The IOA Primary Option menu is dynamically generated according to the products and options available to the user. The INCONTROL administrator can optionally customize the environment so that specific products and options are available only to certain users or user groups.

The IOA Primary Option menu is displayed in one of two formats, depending on the number of options available to the user.

Table 2 Formats for the IOA Primary Option Menu

Format

Description

Line Format

Options are listed one per line with a description of each option.

Box Format

Options are grouped according to product. Descriptions are not displayed.

Reducing or increasing the number of available options may change the format in which the IOA Primary Option menu is displayed.

For a description of menu format and customization, see IOA Administration.

Logic

This section discusses various components of INCONTROL products.

Automated Processing Definitions

Automated processing definitions enable the user to define the tasks to perform and when to perform them. Automated processing definitions contain statements that describe actions to be performed and criteria that define when, and under what conditions, the actions are performed. Each INCONTROL product contains a definition facility by which automated processing is defined.

Automated processing definitions are referred to as jobs, rules, or missions – depending on the INCONTROL product and type of definition.

Online methods for creating automated processing definitions are described in the online facilities chapter of the user guide for each INCONTROL product.

Job and rule and mission definitions are stored in tables, called members, in partitioned datasets. Definitions are activated by scheduling or ordering them to an active environment, which can be a file or memory, depending on the product. Only then can the product process these definitions.

The different types of automated processing definitions are described in the following sections.

Jobs

Job scheduling definitions are used by Control‑M to handle job processing. They can be defined for jobs, started tasks, and so on. Each job scheduling definition indicates scheduling criteria and/or conditions to be met before Control‑M schedules or submits a particular job. Each definition also indicates actions to be performed by Control‑M after the job terminates. Control‑M can perform different post‑processing actions, depending on the execution results.

Control‑M/Restart parameters and statements are also defined in Control‑M job scheduling definitions.

Missions

Missions are used by Control‑D and Control‑V to determine actions to be performed on job output. When a mission’s scheduling criteria are met, the actions indicated by the statements in the mission definition are performed.

Missions are used by Control‑M/Analyzer to define scheduling criteria to be applied to Control‑M/Analyzer rules that indicate actions to be performed.

Rules

Rules are used by Control‑O, Control‑M/Tape, the Control‑M Event Manager (CMEM), and Control‑M/Analyzer to respond to specified events, such as the detection of a message by Control‑O. The occurrence of the specified event triggers the rule that results in the performance of the actions specified in the rule.

Scheduled rules remain active in memory after the performance of the rule. They can be triggered each time an occurrence of the specified event is detected. There is no limit to the number of times a rule can be triggered.

Control‑M/Analyzer rule definitions contain only action statements. Control‑M/Analyzer rules are either executed upon request without regard to scheduling criteria, or according to scheduling criteria specified in a Control‑M/Analyzer mission.

Monitors

Monitors are started tasks that perform IOA functions. There are two types of monitors—IOA monitors and product monitors.

For instructions on activating and deactivating each monitor, see the user guide for the relevant INCONTROL product.

The following sections briefly describe each monitor and its functions.

IOA Monitors

IOA monitors perform tasks that can be initiated from any of the INCONTROL products.

IOA Online Monitor (IOAOMON)

The IOA Online monitor interacts with various environments, such as CICS, to provide the online interface for IOA applications. The IOA Online monitor generates the INCONTROL product screens and handles all IOA Online functions.

This monitor usually operates 24 hours a day as a started task is usually activated automatically as part of the IPL process.

For more information, see IOA Administration.

IOA VTAM Monitor (IOAVMON)

The VTAM monitor (IOAVMON) enables access to the IOA Online monitor for VTAM users without passing though any TP monitors, such as CICS or IMS/DC.

IOA Functional Monitor (IOAFMON)

Control‑M/Tape uses the IOA Functional monitor to process certain action statements, such as DO CONDITION and DO SHOUT.

When an event such as a volume being checked in or a dataset being created occurs, and that event requires execution of an action statement using the Functional monitor, the Control‑M/Tape component writes a trace record that describes the needed action. The IOA Functional monitor reads the Control‑M/Tape Trace file and processes the specified records.

This monitor also accepts requests to be passed to robot tape libraries, and processes them. For more information, see the Control‑M/Tape User Guide, and the IOA chapter of the INCONTROL for z/OS Installation Guide: Installing.

IOA Archive Server Monitor (IOASMON)

The Archive server enables Control-V users to view and print reports that have migrated to non-DASD media.

IOAGATE (IOA Gateway Monitor)

IOAGATE is used by various application servers including the Control-M Application Server (CTMAS), Control-D/Page On Demand facility (CTDAS), and the Control-O Application Server (CTOAS). For information about IOAGATE hardware and software requirements and about installing IOGATE for communication support to Control-D and Control-O, see the IOA chapter of the INCONTROL for z/OS Installation Guide: Installing.

Product-Specific Monitors

Specific product monitors are responsible for many of the automated operations performed by each product.

Control-M

The Control-M monitor scans its active environment file and other files to determine when jobs are submitted. It submits jobs, tracks their execution and analyzes the results.

If Control-O is not installed and the Control-M CMEM facility is active, a CMEM monitor processes CMEM rules that were triggered by events in the system.

Control-O

The Control-O monitor processes rules that were triggered by events in the system and records statistics on rule activation and message detection.

If Control-M is installed, the Control-O monitor also assumes responsibility for processing CMEM rules.

Control-D and Control-V

Control-D activates two monitors, the Control-D monitor and the Printers Control monitor. The Control-D monitor scans its active environment file and other files to determine when missions are processed. It processes missions, tracks their execution and analyzes the results.

If Control-V is installed, this monitor also handles indexing of reports and their migration to other storage media, such as optical storage or cartridges.

The Control-D Printers Control monitor creates subtasks for each print mission, thus enabling parallel execution of print missions.

If Control-D/WebAccess Server is installed, the Control-D file Transfer monitor can transfer Control-D/WebAccess Server packets from the mainframe to the PC. This monitor scans the Active Transfer file and determines which packets are transferred. Control-D and Control-Vdescribes the File Transfer monitor.

The Control-D Application server provides access to Control-D and Control-V User Report files by Control-D/Page on Demand. It is activated by the IOA Gateway monitor. For more information, see Control-D and Control-V.

Daily Processing and New Day Processing

For most INCONTROL products, there are a number of tasks that are performed each day. Typical daily tasks are

  • updating the active file or memory environment with definitions for the new day

  • checking files for integrity and validity

  • producing general reports that describe the actions taken during the previous day

  • housekeeping and cleaning unneeded information from product and IOA files

These tasks are performed automatically using the New Day procedure for each product. The New Day procedure is a program that automates daily maintenance tasks and automatically schedules processing definitions for each day.

For a description of the New Day procedures and User Daily jobs for a specific INCONTROL product, see the relevant chapter (for example, Control-M).

File Management

There are two major ways to classify files used by INCONTROL products:

  • according to access method

    • files managed using a common internal access process called the IOA Access Method

    • files managed using standard access methods

  • according to usage

    • IOA Core files that are shared among INCONTROL products

    • product repository files that are exclusively used by a particular INCONTROL product

IOA Access Method

Certain INCONTROL products have files that are managed using an internal file access process called the IOA Access Method.

IOA Access Method files are sequential datasets with an indexed, or keyed, file structure that offers enhanced data integrity. They are managed (for example, allocated, formatted, and accessed) using a special set of IOA utilities. For more information, see the INCONTROL for z/OS Utilities Guide.

Most IOA Access Method files consist of two separate sequential datasets:

  • a data component, where the actual information resides

  • an index component that provides keyed access to records in the data component

Some IOA Access Method files contain only an index or data component.

Both index and data information are stored in a compressed format that reduces I/O processing overhead and improves disk space utilization.

The IOA Access Method provides dual mirror image file support. This mechanism enables a quick recovery of IOA Access Method files if a disk crash occurs on a disk that contains IOA Access Method primary files.

For a description of the IOA Access Method, see IOA Administration.

IOA Core

The IOA Core is a collection of files that are shared by all INCONTROL products at your site. The following files comprise the IOA Core:

IOA Log File

Contains messages generated by INCONTROL products. Messages can be viewed using option 5 in the IOA Primary Option menu. The IOA Log file is cyclic. The maximum number of messages that can be stored in (specified in an installation parameter. Each new entry in the IOA Log file overwrites the oldest existing entry if required.

For a description of the IOA Log file for a specific INCONTROL product, see the online facilities chapter in the relevant user guide.

The IOA Log file can be indexed by the Control-M ORDER ID of the job. The corresponding Index file should be a separate file. The use of the Index file is optional, and can be activated or deactivated dynamically by the IOA administrator. For more information, see IOA Log Index.

IOA Conditions File (CND)

The CND contains information on the status and availability of conditions system-wide. IOA conditions and resources can be viewed using option 4 in the IOA Primary Option menu. The following information is included in this file:

  • Prerequisite conditions are userdefined conditions set as either "in conditions" (using IN statements), or "out conditions" (using OUT and/or DOCOND statements), in job, rule, and mission definitions

    • When a condition is defined as an "out condition", it is set in the IOA Conditions file during or following the processing of the job, rule, and mission.

    • When a condition is specified as an "in condition", the condition must exist in the IOA Conditions file before the job, rule, and mission can be processed.

  • Prerequisite conditions can be used to make the execution of one job, rule and mission dependent on the execution of another. For example, a job with a particular "in condition" cannot be submitted until a job with the same condition specified as an "out condition" was executed and set the condition.

  • Prerequisite conditions can also be used to indicate that a required manual operation has been performed.

For more information regarding the use of the IOA Conditions file, see the online facilities chapter of the relevant product user guide.

Manual Conditions File

This file contains prerequisite conditions that must be added manually. These include conditions that are required by jobs in the active environment but that are not automatically added by other jobs in the active environment. Typical manual conditions are based on events such as "tape has arrived" or "input has been verified".

Calendar Tables

Calendars determine on which days automated process definitions (jobs, rules and missions) are processed. Calendars can be used to simplify the definition of scheduling criteria.

IOA calendars are organized on a yearly basis. Each calendar lists all the days in a specified year with an indication that an automated definition is or is not processed that day.

Each calendar is assigned a unique name. The calendar name can be specified using Basic Scheduling parameters of an automated processing definition.

Calendars can be defined as either regular or 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) that can be fixed according to monthly patterns.

    Regular calendars are especially useful when a large number of jobs have the same schedule. Defining the schedule once in a calendar and specifying the calendar name in the automated processing definitions with that schedule makes it unnecessary to individually define that schedule in each definition.

  • Periodic calendars are especially useful when basic scheduling criteria do not conform to fixed date or day of the week or month breakdowns. For example, you may need to schedule a particular job every ten days regardless of date.

For a description of the IOA Calendar facility for a specific INCONTROL product, see the online facilities chapter of the user guide for that product.

Variable Database Files

Set of three files describing information in IOA variable databases, which are accessible using option IV in the IOA Primary Option menu. IOA variable database files are managed using the IOA Access Method.

Product Repositories

Each INCONTROL product uses a variety of different files to accumulate information about its operations. These files are referred to collectively as product repositories, regardless of their access method. The table below describes some of the files in the repository of each INCONTROL product. For more information about the repository for each product, see the introduction chapter of the relevant user guide.

In addition to the following list, libraries and tables that contain automated process definitions for each INCONTROL product are also part of each INCONTROL product repository.

For more information regarding the user of the Control‑M Resources file, see the chapter that discusses job production parameters in the Control‑M for z/OS User Guide.

Table 3 Control-M Repository Files

File

Description

Active Jobs file

The Control‑M active environment contains copies of the ordered job scheduling definitions and the status of those jobs. Accessible using option 3 in the IOA Primary Option menu.

The Active Jobs file must not be placed under the control of a product that does not support BDAM file structure, such as Hiperbatch or DLF.

Journal files

The Journal files include the log of Control‑M events (JRNL) and base images of files at the time of the New Day Procedure (CKPJNL and CNDJNL). Together, the Journal files enable you to restore your Active Jobs files in case of a problem.

Job Statistics file

Job execution statistics, such as elapsed time for each job. Updated using utility CTMJSA. Accessible using option S in the Active Environment screen, which is accessed using option 3 in the IOA Primary Option menu.

Job Network file

Dependency information about jobs in the Active Jobs file. Accessible using option N in the Active Environment screen, which is accessed using option 3 in the IOA Primary Option menu.

Resources file (RES)

The Control‑M Resources file contains information on the status and availability of resources system wide. Resources and conditions can be viewed using option 4 in the IOA Primary Option menu. The following types of resources are included in this file:

Quantitative

Quantity of a resource in the system. Different jobs may require different quantities of specific resources. For example, a job may require two tape drives.

Specification of Quantitative resource requirements for a job provides a solution for the allocation of quantitative computer resources, including, for example, cartridge drives, CPU utilization, database access rate. Specification of Quantitative resource requirements increases computer throughput by controlling access to these resources, thus preventing execution bottlenecks.

Control

Shared or Exclusive usage of a specific resource. Some jobs may require a resource to be in a specific mode. For example, a backup job may require exclusive access to a specific dataset.

Specification of Control resource requirements for a job or mission provides a solution for the problem of resource sharing between different jobs. The Exclusive or Shared mode in which a Control resource is required by a job is also specified.

IOA considers the mode of resource usage required when allocating Control resources and prevents jobs whose resource usage is incompatible from executing simultaneously.

Table 4 Control-D and Control-V Repository Files

File

Description

Active Missions file

The Control‑D and Control‑V active environment contains copies of pending, executing and recently executed missions, and mission status. Accessible using option A in the IOA Primary Option menu. Managed by the IOA Access Method.

User Report List files

Information about reports sent to a specific user. Reports can be selected for Online Viewing, deleted, and transferred to other users. Accessible using option U in the IOA Primary Option menu. Managed by the IOA Access Method.

Types of User Report List files:

Permanent

A list of all reports defined to Control‑D.

Active

Recently or soon to be processed reports.

Migrated

Reports migrated from DASD to various storage devices (Control‑V only).

History

Reports backed up on tape or cartridge.

Active Transfer file

Information about packets that are scheduled for transfer to a PC. Only relevant for sites with Control‑D/WebAccess Server. Accessible using option F in the IOA Primary Option menu.

Table 5 Control-O Repository Files

File

Description

Message Statistics file

List of all messages and commands detected in the system, and various information about messages. Examples include frequency, and whether the messages were suppressed. Accessible using option OM in the IOA Primary Option menu.

Automation log

Automation information about all input available to Control‑O:

  • Console, IMS, and CICS messages and commands.

  • ControlO internal messages.

  • ControlO rule traces.

The Automation log can be accessed using option OL in the IOA Primary Option menu.

Global Variables library

List of all user‑defined Global variables. The members of this library are loaded when Control‑O is started These members can be defined or updated using various operator commands. A backup sequential file with the .COPY suffix also exists under the name of the specified Global Variables library.

Global Variables Database

List of all user-defined Global variables. The pools are stored in the IOA Global Variables Database files and are loaded when Control-O is started These databases can be defined or updated using various operator commands. See IOA Core.

Table 6 Control-M/Analyzer Repository Files

File

Description

Active Balancing file

List of all Control‑M/Analyzer missions loaded during the Control‑M/Analyzer New Day procedure and information about rule status. Accessible using option BB in the IOA Primary Option menu.

Control‑M/
Analyzer
Report file

Detailed information (Balancing report) about each invoked Control‑M/Analyzer rule. Accessed using option R in the Rule Activity screen (option BA).

Database files

Information about each Control-M/Analyzer Database variable. The Database tracks the generations, or previous and current values, of each variable.

Table 7 Control-M/Tape Repository Files

File

Description

Media Database

Information on all datasets and volumes managed by Control‑M/Tape.

Trace file

Record of activities in the Control‑M/Tape environment. Used primarily for recovery of the Media Database.

Stacking Database

Statistical information on each dataset that is used by Control‑M/Tape to estimate the amount of space required for that dataset. Information about previous generations of the dataset is used to calculate space requirements for storage of each dataset as well as to calculate the average life span of the dataset (non-specific retention criteria). Information used to calculate the average life span of the dataset include catalog, date since last access, and so on.

Statistical information can be extracted from repository files using various utilities and KeyStroke Language (KSL) reports:

For a description of the utilities, see the INCONTROL for z/OS Utilities Guide.

For a detailed description of information extraction using KSL reports, and sample KSL reports for a specific INCONTROL product, refer to the KeyStroke Language User Guide.

IOA and Product PARM Libraries

A wide variety of IOA and INCONTROL product features utilize PARM libraries. Members of these PARM libraries do not contain sequential line numbers in columns 72 through 80.

Miscellaneous

Dynamic Destination Table

The IOA Shout facility allows the user to specify messages to be sent to particular destinations upon the occurrence of specified events. However, it may be necessary to send a particular message to several destinations, and/or a particular physical destination may vary depending on time of day or other factors. For example, the TSO logon ID of the shift manager may be different for each shift.

These situations are handled by defining groups of destinations in a Dynamic Destination table. The Dynamic Destination table consists of a site‑defined list of logical destination names. For each logical, or group, destination name, a list of physical destinations is defined. The table can include all possible types of Shout destinations, including E-mail, TSO, SNMP trap, and operator consoles.

A logical destination name can be specified for a Shout message. The message, when shouted, is sent to each physical destination defined to the logical location. If the physical location is logged on, it receives the message.

Multiple Dynamic Destination tables can be defined, one of which is defined as the default. This Dynamic Destination Table is loaded when the product‑specific monitor, such as the Control‑M monitor, is started. A different Dynamic Destination table can be loaded using the operator command. However, only one table can be loaded at time.

Shout messages are directed by the product‑specific monitor to the Dynamic Destination table in memory.

When a change is made to the Dynamic Destination Table in memory, and it is desired that the change be implemented immediately, the table is reloaded into each product’s memory. For information about loading and reloading Dynamic Destination tables in memory, see IOA Administration.

Mail Destination Table

The IOA Shout facility allows the user to specify messages to be sent to particular destinations upon the occurrence of specified events. These events include to mail destinations and distribution lists.

These situations are handled by defining e-mail addresses and distribution lists in a Mail Destination table. The Mail Destination table consists of a site‑defined list of logical e-mail destination names and e-mail distribution lists. For each logical, or group, e-mail destination name, a list of e-mail address destinations is defined.

Multiple Mail Destination tables can be defined, one of which is defined as the default. This Mail Destination table is loaded when the product‑specific monitor, such as the Control‑M monitor, is started. A different Mail Destination table can be loaded using operator command.

Shout messages are directed by the product‑specific monitor to the Mail Destination table in memory.

When a change is made to the Mail Destination Table in memory, and it is desired that the change be implemented immediately, the table is reloaded into each product’s memory. For information about loading and reloading Mail Destination tables in memory, see IOA Administration.

SNMP Destination Table

The IOA Shout facility enables the user to specify messages to be sent to particular destinations, including SNMP destinations, upon the occurrence of specified events. These situations are handled by defining SNMP IP addresses in an SNMP Destination table, which consists of a site-defined list of SNMP IP addresses and logical SNMP destination names. The list defines the following items for each SNMP address:

  • IP address

  • logical or group

  • SNMP destination name

Multiple SNMP Destination tables can be defined, one of which is defined as the default. This SNMP Destination table is loaded when the product-specific monitor, such as the Control-M monitor, is started. A different SNMP Destination table can be loaded using operator commands.

Shout messages are directed by the product-specific monitor to the Dynamic Destination table in memory.

When a change is made to the SNMP Destination Table in memory, and the change should be implemented immediately, the table is reloaded into memory for each product memory. For information about loading and reloading SNMP Destination tables in memory, see IOA Administration.

AutoEdit Facility

The AutoEdit facility uses AutoEdit variables to enable symbolic representation of dynamic values, such as values that change from execution to execution, or from day to day. Each variable is resolved at the appropriate time, and the resolved value is substituted for the variable. Special AutoEdit functions and control statements enable manipulation of values specified for these variables. The variables can be used in job, rule and mission definitions in various ways allowing flexibility and high level logic in automation of your work environment.

In addition, AutoEdit variables and functions can be used in different ways for each INCONTROL product. The AutoEdit facility can be especially useful in

  • JCL setup of jobs submitted under ControlM

  • messages issued with the IOA Shout facility

  • report scripts written in the KeyStroke Language (KSL)

  • KeyStroke OpenAccess scripts used by ControlO to interact with VTAM applications

For information about using the AutoEdit facility with the products at your site, see the relevant user guides.

The dollar sign ($) is a reserved prefix of IOA AutoEdit variable names.

Security Implementation

INCONTROL products can be protected just like any other data center application. IOA has built‑in interfaces to widely used security environments, such as RACF, CA‑ACF2 and CA‑TOP SECRET. Each IOA function is associated with a security module. These security modules are used to check user authorization for requested actions, and to permit or deny the actions accordingly. User exits are invoked before the security modules to allow the user to perform required user functions that are not related to security.

For a detailed description of IOA security, see the INCONTROL for z/OS Security Guide.

User Exits

IOA user exits can influence the continued operation of an INCONTROL product at specific points in processing. For example, an exit can check user authorization for a specific action or modify report banners and indexing before printing.

For a description of exits, see Exits. Detailed information about each exit is provided at the beginning of each default user exit source member in the IOA SAMPEXIT library.

Utilities

Utilities are specialized programs designed to perform specific tasks in the INCONTROL product environment. Some utilities are used with all INCONTROL products and some are product-specific.

For a description of most INCONTROL product utilities, see the relevant chapter in the INCONTROL for z/OS Utilities Guide. (The introduction chapter includes a list of these utilities). For a description of utilities not described in the INCONTROL for z/OS Utilities Guide, see the user guide of the relevant product.

For a description of online utilities, see the online facilities of the relevant user guide.

Simulation

Prior to running a complex task for the first time, or during a conversion from another product, it is often useful to be able to first perform the task, or conversion, in simulation mode. For this reason, certain INCONTROL products and utilities can be run in simulation (TEST) mode.

In simulation mode, the INCONTROL product or utility does not affect your system. but does generate information that is useful for checking performance.

Cross Product Communication

Certain INCONTROL products can perform actions in response to information received from another INCONTROL product.

The following sections describe some ways in which INCONTROL products can interact:

File Access

IOA Core files are accessed by more than one product. A change made in one of these files by one product can then be read by another INCONTROL product. For more information on files shared by INCONTROL products, see the description of the IOA Core.

A prerequisite condition set by Control‑O is detected by Control‑M during its next scan of the IOA Conditions file. As a result of the detected condition, Control‑M can then run a job whose execution is dependent on this condition (that is, the condition is specified in the job’s IN parameter).

Automated Processing Definition Statements

Some statements in automated processing definitions, such as job scheduling definitions, can be used by one INCONTROL product to directly influence the operation of another INCONTROL product.

The DO FORCEJOB statement can be used by other INCONTROL products to instruct Control‑M to force, or unconditionally schedule, a specified job.

Parameter CTB STEP specified in a job scheduling definition can trigger a Control‑M/Analyzer rule.

Special CrossProduct Interfaces

Some INCONTROL products have special interfaces to other INCONTROL products installed at the same site. For a discussion of interfaces for specific combinations of INCONTROL for z/OS products, see the relevant chapters.

Control‑M/Restart has a special driver exit that it uses to interface with Control‑M/Tape.