Introduction to Control-M/Assist

This chapter contains the following topics:

• Who should read this book

• Overview

  • How does it work?

• Control-M/Assist main components

  • IOA

  • Control-M

  • CMEM

  • IOAGATE

  • Control-M Application Server

  • Overall look at the Control-M/Assist environment

• Terminology

Who should read this book

This document explains Control-M/Assist and addresses the following:

• Environment

  • Third-party-vendor scheduling product users other than Control-M for z/OS in your mainframe environment (for example, IBM's OPC/ESA or Computer Associates' CA-7).

  • Control-M/Server and Control-M/EM for distributed applications running on UNIX or Microsoft Windows operating systems.

• Task needs

  • Trigger a job execution in the distributed environment by Control-M/Server after the completion of a job on the mainframe side.

  • View jobs which executed in the mainframe in the Control-M/EM Active environment (colored according to their completion status)

  • Raise an Alert in the Control-M/EM Alert window for jobs executed in the mainframe depending on their completion status.

  • Trigger the execution of a job in the mainframe after the completion of a job scheduled by Control-M/Server in the distributed environment.

Overview

Control-M/Assist is a solution set designed for customers that use a third-party scheduling product on their mainframe (that is, a scheduler other than Control-M for Z/OS), but that use Control-M for Distributed Systems (Control-M/Server and Control-M/EM) in their distributed environment.

It enables these customers to control and track the entire scheduling enterprise, including the Z/OS environment, through Control-M/EM.

Control-M/Assist does the following:

• detects jobs submitted manually or by a non-Control-M scheduler into the batch workload of the z/OS environment.

• automatically forces the schedule definition of those jobs into the active environment of Control-M.

• utilizes the job scheduling definitions forced into the Control-M Active Environment to control and define the processing logic that should be executed for that job, for example, creating shout and alerts messages, handling the job SYSOUT, and sending an e-mail.

• enables you to monitor the jobs are forced into the Control-M Active Environment, through the centralized control station of Control-M/EM. Using Control-M/EM. For more information, see Monitoring mainframe jobs from Control-M/EM.

• enables you to create bidirectional jobs dependencies among jobs on any platform (UNIX, Microsoft Windows, and so on) in the distributed environment and jobs in the z/OS environment. For more information, see Cross-platform jobs, managed by Control-M/EM, trigger z/OS jobs.

How does it work?

All the Control-M/Assist software components are installed on your z/OS environment.

Using the Control-M Event Manager (CMEM) facility, defined jobs can be captured when submitted for execution by the non-Control-M scheduler, and their schedule definition will then be forced in the Control-M Active Job environment. The Control-M for z/OS monitor then executes the processing logic you defined in the Job Schedule Definitions.

Finally, using the Control-M Application Server and the IOAGATE, the information is transferred between Control-M for z/OS and Control-M/EM. See OOverall look at the Control-M/Assist environment for a graphic presentation and detailed explanation.

Control-M/Assist main components

Control-M/Assist consists of the BMC components described in the following sections:

IOA

The Control-M for z/OS Automated Production Control and Scheduling System is a component member of the INCONTROL family of products, a fully integrated suite designed to automate, manage and streamline operations on the z/OS mainframe.

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 architectural 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

For further details, see the section about INCONTROL products and IOA in the Control-M for z/OS User Guide.

Control-M

Control-M automates job processing in your data center. Control-M

• performs virtually all the job handling tasks of computer operators.

• provides an interface that enables the user to intervene in the process of production management.

• provides continual data and status information regarding job processing.

This chapter introduces the Control-M facilities and components from a functional perspective, beginning with the major components that comprise the heart of Control-M and progressing to the less major components that enhance the functionality of Control-M.

The following components are essential to Control-M:

• Job scheduling definitions

• Active Jobs File (AJF)

• Control-M monitor

Job scheduling definitions

A job scheduling definition specifies criteria that identify decisions to be made, and actions to be taken, regarding the handling of a particular job. Each job scheduling definition contains the following sections:

• General Parameters

  General information about the job (for example, identify the library and member in which the JCL is stored).

• Basic Scheduling Parameters

  Criteria according to which Control-M schedules the job.

• Runtime Scheduling Parameters

  Runtime requirements that must be satisfied before Control-M submits the job.

• Post-processing Parameters

  Actions Control-M performs after the job ends, depending upon the outcome of job execution. For example, Control-M performs one set of actions if the job ends OK, but another set of actions if an abend occurs.

Users of Control-M/Assist are required to define Job Scheduling definitions for jobs or groups of jobs to be managed by Control-M/Assist. When defining jobs definitions in Control-M/Assist environment, consider the following:

• Job definition Basic scheduling parameters and the Runtime Scheduling sections are irrelevant to Control-M/Assist users since the jobs are scheduled externally to Control-M.

• The post-processing section is the most relevant section and specifies the Control-M post-processing logic to be executed after the job enters the Control-M/Assist environment.

The mechanisms used to define job scheduling definitions are discussed in the online facilities chapter of the Control-M for z/OS User Guide.

Once defined, a job scheduling definition is saved. It can be modified later if required. Job scheduling definitions are stored in members in partitioned datasets (libraries), as follows:

• Job scheduling definitions for related applications are generally placed in a single member, called a table.

• Multiple tables are stored in partitioned datasets, called scheduling libraries.

• Multiple scheduling libraries can be defined.

Active Jobs File

Each job scheduling definition contains criteria that determine whether the job must be scheduled on a given day. If based on these criteria a job must be scheduled, a copy of its job scheduling definition is placed in a file called the Active Jobs File. The mechanism by which job scheduling definitions are placed in the Active Jobs File is discussed in the job ordering and job forcing section of the Control-M for z/OS User Guide. Only jobs in the Active Jobs File are candidates for submission by the Control-M. In the Control-M/Assist environment, however, jobs are scheduled and submitted externally to Control-M.

In the Control-M/Assist environment, CMEM rules capture JOBARRIVAL events, forcing the jobs definition to the Active Job File as a special kind of jobs known as ONSPOOL jobs (jobs that Control-M needs to post-process but not to submit).

Control-M monitor

The Control-M monitor handles and controls job processing as follows:

• Checks the runtime requirements specified in each job scheduling definition in the Active Jobs File, monitors available resources and conditions in the environment, and when it determines that the conditions and resources required by a job are available, it allocates the resources and submits the job.

• In the Control-M/Assist environment jobs are submitted externally to Control-M.

• Monitors the execution of the job.

• Implements post-processing decisions based on instructions in the job scheduling definition and the results of the job execution. This phase enables CTM/Assist users to trigger activities in Control-M/DS.

The Control-M monitor operates continuously. It evaluates the production environment and implements decisions.

Expanded Control-M functionality

This following features and capabilities of Control-M are described in details in the Control-M for z/OS User Guide and the INCONTROL for z/OS Administrator Guide.

Automating job scheduling: New Day processing

The mechanism used to place job scheduling definitions automatically on the Active Jobs File is called New Day processing. At a set time each day, Control-M performs New Day processing, during which:

• Control-M performs a number of maintenance and cleanup functions.

• Job scheduling definitions are selected from the tables and are placed in the Active Jobs File. These jobs can then be submitted and tracked by the Control-M monitor.

Automatic JCL update: JCL and AutoEdit facility

The JCL and AutoEdit facility offers a method to automate manual JCL update activities.

Automated job submission

Automated job submission controlled by runtime scheduling criteria.

Monitoring of resources

Three types of runtime criteria resources can be monitored by Control-M: Conditions, Quantitative resources and control resources. Only when the conditions and resources required by a job are available is the job submitted by the monitor.

Immediate detection and notification of problems: Shout facility

When a problem or an unexpected situation or delay occurs, Control-M can notify the appropriate personnel using the shout facility.

History Jobs File

During New Day processing, jobs that have ended OK are deleted from the Active Jobs File and can be placed in the History Jobs File.

Journaling and restoration capability

Permits forward recovery of the Control-M environment to any time of the day you may choose.

IOA Log facility

Provides a message repository through which the user can examine messages issued by Control-M during the processing of a job.

Automated job post-processing

Once the job has executed, the Control-M monitor implements the post-processing instructions defined in the job scheduling definition.

Utilities

Utilities provided with Control-M are used to perform a variety of management functions and generate reports that assist in the efficient use of Control-M.

Using calendars to schedule jobs: IOA Calendar facility

Specification of scheduling criteria for jobs can be simplified by using calendars. A calendar defines which days jobs should be ordered.

Accumulating statistics: Statistics facility

All accumulated information regarding job execution, including the elapsed run time, is written to the IOA Log file. Periodically, a statistics utility may be used to scan and analyze the IOA Log file.

Automatic Tape Adjustment facility

The Automatic Tape Adjustment facility collects and analyzes statistics regarding tape drive usage to automatically allocate the appropriate number of tape drive resources at job order time.

Reporting facility

Control-M supports a comprehensive reporting facility.

Reports description

Keystroke Language (KSL) is a general purpose reporting language, based on the online facility, capable of producing numerous reports from the database.

Online user interface to Control-M

Control-M provides an online user interface that enables the user to

• interface with most of the previously described facilities

• intervene in the process of production management

• immediately access up-to-date information from the production environment

Scheduling Definition facility

The Control-M Scheduling Definition facility is accessed through Option 2 of the Primary Option menu. It is the main online facility for creating, defining, modifying, and deleting tables and job scheduling definitions. In addition, this facility can be used to

• edit the JCL of a job

• produce a job (scheduling) plan

• display job statistics

• copy a job definition

• manually order or force jobs

• graphically display a job flow of the jobs in a table

Active Environment (Status) screen: Online Tracking and Control facility

The Online Tracking and Control facility is accessed through Option 3 of the IOA Primary Option menu. It is the main user interface to the monitoring of the jobs scheduled for the day.

In the Online Tracking and Control facility, you can perform the following functions:

• View the status of each job order in the Active Jobs File

• Place a job in HELD status or free a HELD job

• Delete a job order

• Obtain a statistical overview of the status of jobs in the Active Environment screen

• See why a job in the Active Jobs File has not been submitted. If job submission is held up due to missing prerequisite conditions, you can optionally add those conditions manually

• Display the Log file of a job to view all messages issued for the job

• Zoom in on the parameters of a job order This includes not only the job scheduling definition parameters, but also parameters determined by the Control-M monitor at runtime. Manual update of most of these parameters for the job order is permitted.

• View the documentation of a job

• Add notes to a job, for example, to document actions that were taken

• Confirm the scheduling, rerun, or restart (if Control-M/Restart is active), of a job that has been defined as requiring manual confirmation

• View the execution history of all orders of a job, and view the job order SYSOUTs

• View the accumulated statistics of successful executions of a job

• View the list of job dependencies for a specific job (that is, the predecessor and successor jobs of the selected job), and perform manual job flow adjustment, such as priority adjustment You can filter which jobs in the Active Jobs File are displayed in the Active Environment screen.

• Simulate job execution

• Bypass runtime scheduling criteria

CMEM Rule Definition facility

The CMEM Rule Definition facility is accessed through Option C of the INCONTROL Primary Option menu. CMEM rules enable Control-M to respond to external events. The CMEM Rule Definition facility is an online facility that enables the user to create, define, modify and delete CMEM rule tables and CMEM rules.

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 and/or resources

• change the available quantity of Quantitative resources

IOA Log screen

The IOA Log screen, accessed through Option 5 of the IOA Primary Option menu, displays the IOA Log file. The IOA Log file contains messages that record every significant event in the life of all jobs or started tasks, rules, missions, and other functions that are under the control of IOA products. This includes messages generated for normal processing, such as job submitted, error conditions (if any) encountered during processing, and messages directed to the Log file from the SHOUT facility.

The user can filter IOA log file contents displayed in the IOA Log screen.

IOA Manual Conditions screen

The IOA Manual Conditions screen is accessed through Option 7 of the IOA Primary Option menu. It displays the IOA Manual Conditions file, which contains the list of prerequisite conditions that must be added manually. These are IN conditions that are required by scheduled jobs but are not added by scheduled jobs, that is, these conditions are not listed as OUT or DO COND conditions in the Active Jobs File. These conditions fall into the following categories:

• Conditions that are never automatically added by scheduled jobs because manual confirmation is always desired.

• Conditions that are normally added automatically by scheduled jobs, but the jobs that add them are not scheduled.

For the conditions listed in the Manual Conditions screen to be added to the IOA Conditions file, manual intervention is required.

The IOA Manual Conditions screen enables the user to:

• View the list of Manual Conditions

• Select and add listed conditions, as desired, to the IOA Conditions file

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 simplify the entering of basic scheduling criteria in job scheduling definitions. The IOA Calendar facility enables the user to create, define, modify and delete IOA calendars.

Online Utility screens (under ISPF)

When Control-M and other INCONTROL products (if any) are active under ISPF, a number of utilities and facilities can be activated online. The IOA Online Utilities menu is accessed through Option 6 of the IOA Primary Option menu (under ISPF). The IOA Online Utilities menu displays available utilities from which the desired utility or facility can be selected.

CMEM

The Control-M Event Manager (CMEM) facility enables Control-M to perform specified actions in response to external events. External events are events in the system that occur outside Control-M's direct control (for example, submission of a job not under the control of the Control-M monitor).

The CMEM facility utilizes sets of user-defined rules that specify events to monitor and actions to perform if a specified event occurs. These rules are defined online through the CMEM Rule Definition facility.

Multiple rules can be defined in a table (member) in a standard partitioned dataset (library). Related rules are usually defined in the same table. Multiple tables can be defined in a library, and multiple CMEM rule libraries can be defined.

The CMEM discussion below contains general and technical information on CMEM for all users. Where noted, not all the requirements and recommendations may be appropriate for Control-M/Assist users.

For more information, see the chapter about the Control-M Event Manager in the Control-M for z/OS User Guide.

Types of events managed by CMEM

The CMEM facility handles the following events that can be specified in ON statements in the rule:

• DSNEVENT – Dataset disposition (such as cataloged, deleted or kept) during step termination or dynamic decollation, or the occurrence of a NOT CATLGD 2 event (when a dataset name is created in a job step but not cataloged because its name already exists in the MVS catalog)

• JOBARRIV – Arrival of a job on the JES spool from any source, for example, jobs submitted by a TSO user or by CICS, or jobs received over an NJE network.

• JOBEND – Completion of a job regardless of its source.

• STEP – Termination of a job step.

Types of actions that CMEM can perform

Any combination of the following actions may be performed when the specified event occurs. They are specified in DO statements in the rule definition:

• DO COND statement – Prerequisite conditions may be added to or deleted from the IOA Conditions file. This may trigger the submission of jobs in the Active Jobs File.

• DO FORCEJOB statement – A Control-M table or individual job can be forced (that is, ordered to the Active Jobs File regardless of its basic scheduling criteria). Jobs can be forced for one of the following reasons:

• To start a new process in Control-M (that is, new job submission).

• To enable Control-M to assume full control of an externally submitted job that triggers the event. These jobs are referred to as onspool jobs, discussed in On Spool jobs.

• DO STOPJOB statement – Stop (terminate) the job in which the event occurs at the end of the current job step.

The following actions can be defined if Control-O is installed:

• DO RULE statement – Control-O rules can be invoked within the current rule.

• DO SHOUT statement – Messages can be sent via the Control-O Shout facility.

CMEM rule ordering, triggering and deactivation

CMEM tables are usually ordered (loaded to memory) when CMEM is started. They can also be refreshed or loaded by an operator command, or manually using the FORCE option in the CMEM Table List screen.

A CMEM rule is triggered (that is, all its DO statements are performed) by the occurrence of the events specified in the rule's ON statements.

More than one rule can be triggered by the occurrence of an event. An event triggers each rule whose ON statement matches the event. Generally, all actions from all triggered rules are performed.

The one exception occurs when multiple rules are triggered by the same job arrival event and more than one of the triggered rules contains DO FORCEJOB statements. In this case, the DO FORCEJOB statements of the first triggered rule are performed, but the DO FORCEJOB statements of the other rules triggered by the event are not performed. For more information, see On Spool jobs.

CMEM rules remain activated (that is, in memory) until they are overridden by the reloading of the rule table or deleted by an operator command.

Control-M/Assist and CMEM

Control-M/Assist uses CMEM in order to captures job arrival events and to force the jobs definition to the Active Job File to enable Control-M to assume full control of an externally submitted job that triggers the event. These jobs are referred to as on spool jobs and are discussed in On Spool jobs.

The CMEM rules defined in Control-M/Assist environment will be triggered by ON JOBARRIVAL events and will use the DO FORCEJOB action to force the jobs definition into the AJF.

On Spool jobs

On Spool jobs are jobs or started tasks that are submitted externally to Control-M, that is, jobs submitted by TSO users or CICS, or jobs received over an NJE network, and brought under the control of the Control-M monitor using a CMEM rule.

The CMEM rule that causes a job to be an On Spool job (that is, a CMEM rule that brings the external job under the control of the Control-M monitor), must be an ON JOBARRIV rule with a DO FORCEJOB statement.

To inform Control-M that this is an On Spool job and not a regular FORCEJOB request, the job scheduling definition forced by the DO FORCEJOB must "match" the arriving job, as described later in this section.

Control-M controls the entire life cycle of the job, from determining when to execute the job to performing job post-processing, according to the forced job scheduling definition.

Control-M processes On Spool jobs slightly differently than it processes regular jobs. Control-M does not submit the job because the job has already been submitted. Instead, Control-M releases the job (if held) when the runtime scheduling criteria are met. Once the job starts execution (whether the job previously required releasing or not), it is controlled by Control-M in the same way that Control-M controls regular jobs. Control-M waits for the job to finish, reads its SYSOUT, and performs all post-processing actions defined in the job scheduling definition.

Creating On Spool jobs

The following components are necessary to create On Spool jobs:

• Job on spool

  The job must have the following characteristics:

  • The MSGCLASS SYSOUT of the job:

    • For JES3 users: must be equal to the Control-M SYSOUT held class.

    • For JES2 users: can be any held SYSOUT class.

      This enables Control-M to read the job's SYSOUT and perform post-processing according to the job scheduling definition.

• To delay the job's execution and permit Control-M to determine when to run it, submit the job with TYPRUN=HOLD.

  Control-M/Assist users may not wish to implement this recommendation.

• Job scheduling definition

  The job scheduling definition must have the following characteristics:

  • The job scheduling definition must be forced by the first DO FORCEJOB statement in the CMEM rule.

  • The MEMNAME value in the job scheduling definition must match the name of the external job. A mask can be specified in the MEMNAME field if the same job scheduling definition is used for more than one job.

  • Appropriate runtime scheduling criteria for the job may be defined in the job scheduling definition. This enables Control-M to control the execution of the job (that is, when the job must be run).

  Control-M/Assist users may not wish to implement this recommendation.

  • Desired post-processing actions must be defined in the job scheduling definition.

• CMEM rule definition

  The CMEM rule definition must contain the following:

  • ON JOBARRIV statement. The job name specified in the ON JOBARRIV statement in this rule must match the name of the job to be monitored. It can be a full job name, or it can be a mask if a group of jobs is to be monitored.

  • DO FORCEJOB statement. The first DO FORCEJOB statement in the rule must force a matching job scheduling definition (described below).

Handling On Spool jobs

On Spool jobs are handled as follows:

• When the job arrival event occurs, Control-M forces the requested table or job.If the MEMNAME value in the requested table or job does not match the name of the arriving job, the table or job is forced and processed regularly by Control-M (a job is submitted when its runtime scheduling criteria are met, and so on).

• If the MEMNAME value in the requested table or job matches the name of the arriving job, the job becomes an On Spool job and Control-M performs the following actions:

  • Replaces the MEMNAME mask (if a mask was specified in MEMNAME) with the name of the arriving Job.

  • Assigns the job ID of the job that triggered the event to the forced job.

  • Forces the job, the forced job appears in the Active Environment screen with status WAIT SCHEDULE ON SPOOL.

• Control-M starts processing the forced job when all runtime scheduling criteria defined in the job scheduling definition are satisfied. If there are no runtime scheduling criteria in the job scheduling definition, Control-M starts processing the job immediately.

• Control-M looks for the job in the spool (to release it, if required).

• If the external job is waiting for execution in HELD state (that is, if the job arrives on spool with TYPRUN=HOLD), Control-M releases it for execution. Otherwise, Control-M verifies that the job is still in the spool (waiting for execution, executing or ended) before deciding to perform post-processing.

• Control-M waits for the job to finish execution, reads its SYSOUT, analyzes the execution results and performs all the post-processing actions defined in the job scheduling definition.

On Spool job scheduling definition considerations

• Job forcing considerations

  Only one On Spool job can be created in response to a job arrival event.

  However, in several cases, multiple DO FORCEJOB actions might match the arriving job. Each of these cases and the job forcing logic applied to them (to prevent multiple On Spool processes for the same external job) are described below.

  • The job arrival rule contains multiple DO FORCEJOB requests. (Each might match the arriving job.) In this case, job forcing logic is as follows:

  • The On Spool process (the match between the external job name and MEMNAME) is performed for the first DO FORCEJOB in the first matching job arrival rule only:

    • If a match is found, the job is an On Spool job.

    • If a match is not found, the job is not an On Spool job, even if subsequent DO FORCEJOB actions might match.

• In either case, all subsequent DO FORCEJOB statements in the same rule (if they exist) are handled normally (that is, not as forcing On Spool jobs).

• The DO FORCEJOB forces a table in which more than one MEMNAME matches the arriving job. In this case, job forcing logic is as follows:

• If a table containing more than one job is forced (by the first DO FORCEJOB statement in the rule, as described above), the first matching job causes the job to be an On Spool job. All the other jobs in the table are forced as regular Control-M jobs, even if they match the job name of the external job.

• Multiple job arrival rules are triggered by the same job arrival event, and each rule contains one or more DO FORCEJOB statements that might match the arriving job. In this case, job forcing logic is as follows:

• Only the DO FORCEJOB statements from the first triggered rule are executed (as described above). DO FORCEJOB from all other triggered job arrival rules are ignored.

JCL management considerations

When defining JCL, the following issues must be considered:

• Any attempt to rerun the job (that is, as a cyclic job, by a DO RERUN statement, or by a manual rerun request) might fail if the JCL of the job is not found in the library specified in the MEMLIB parameter of the job scheduling definition.

• If the job is not submitted with TYPRUN=HOLD, Control-M cannot determine when the job runs, even if runtime scheduling criteria are defined. In this case, the job might start executing before all the runtime scheduling criteria are satisfied. Post-processing, however, is not performed by Control-M until the runtime scheduling criteria are satisfied.

• The JCL of the On Spool job cannot contain AutoEdit statements, and SETVAR statements in the job definition are ignored. This is because the job is not submitted by Control-M.

• Because the job is not submitted by Control-M, the following job scheduling definition parameters are ignored:

  • SCHENV

  • SYSTEM ID

  • NJE NODE

  • NJE enhanced tracking support is inoperative

IOAGATE

IOAGATE is communications gateway software (middleware) on the mainframe that enables IOA mainframe applications to communicate with other, mainframe and non-mainframe, applications over the network.

Client applications access INCONTROL products by means of an application server through IOAGATE.

The application server is a separate address space distinct from the IOAGATE address space. It is started by IOAGATE according to IOAGATE parameters. The responsibility of the application server is to handle the application logic, while IOAGATE performs the actual communications and passes the messages between the clients and the application servers.

IOAGATE supports multiple concurrent application servers of different applications and their clients. A single IOAGATE can support Control-M, Control-D/Page On Demand, Control-D File Transfer Option, Control-D/WebAccess Server, and Control-O applications.

For further details regarding IOAGATE refer to

• the IOAGATE chapter in the INCONTROL for z/OS Administrator Guide

• the section about IOAGATE configuration in the INCONTROL for z/OS Installation Guide

• Step 20, Install IOAGATE in the installing IOA chapter in the INCONTROL for z/OS Installation Guide

Control-M/Assist and IOAGATE

The Control-M/Assist environment uses the IOAGATE gateway to connect between the Control-M Application Server and Control-M/EM, which enables the customer to control the z/OS work from the Control-M/EM control panels.

Control-M Application Server

Using the IOAGATE and the CTMAS (Control-M Application Server) a connection between Control-M for z/OS environment and the Control-M/EM is established.

The following example illustrates communication between Control-M on an MVS platform with Control-M/EM (via IOAGATE and CTMAS).

For further details, see Step 21, Install Control-M Application Server in the installing IOA chapter in the INCONTROL for z/OS Installation Guide.

Overall look at the Control-M/Assist environment

This section describes the Control-M/Assist environment data flow and ties together all the Control-M/Assist components into a single framework.

• Step 1 – Jobs are submitted for execution on the z/OS environment externally to Control-M. The jobs can be submitted by scheduling products or by any other alternative method (TSO submit command, user programs, and so on). After jobs are submitted, they arrive on the JES spool.

• Step 2 – CMEM facility captures the job arrival events defined by the CMEM rule definitions that were activated (loaded to CMEM memory via an order/force command or via operator modify command). Using the action DO FORCEJOB that is specified in the CMEM rules, the jobs definitions are forced into the Active Jobs File and become onspool jobs. For more details, see On Spool jobs.

• Step 3 – After the CMEM rule brings the external job under the control of the Control-M monitor, Control-M releases the job (if held) when the runtime scheduling criteria are met, and once the job starts execution (whether the job previously required releasing or not), it is controlled by Control-M in the same way that Control-M tracks regular jobs. Control-M waits for the job to finish, reads its SYSOUT, and performs all post-processing actions defined in the job scheduling definition.

• Step 4 – Communication between Control-M/EM and a Control-M for z/OS environment is established through IOAGATE and Control-M Application Server. After a connection is established via the TCP/IP or APPC communication protocol, information is transferred between Control-M/EM and Control-M for z/OS.

• Step 5 – Control-M/EM, which runs on UNIX and Microsoft Windows workstations, provides centralized control of the job scheduling production environment for the entire enterprise, including the z/OS environment batch work. Users can now monitor z/OS jobs from Control-M/EM GUI panels.

Terminology

Refer to the relevant conversion guide listed below to familiarize yourself with the parallel Control-M technology:

• Control-M for z/OS A-AUTO Conversion Guide

• Control-M for z/OS ADC2 Conversion Guide

• Control-M for z/OS APEX Conversion Guide

• Control-M for z/OS APM/HS5000 Conversion Guide

• Control-M for z/OS CA-7 Conversion Guide

• Control-M for z/OS CA-JOBTRAC Conversion Guide

• Control-M for z/OS CA-MANAGER Conversion Guide

• Control-M for z/OS CA-SCHEDULER Conversion Guide

• Control-M for z/OS CA-ESP Conversion Guide

• Control-M for z/OS DJC Conversion Guide

• Control-M for z/OS for OPC/A, OPC/ESA, Tivoli Workload Scheduler (TWS), and IBM Workload Scheduler (IWS) Conversion Guide

• Control-M for z/OS ZEKE Conversion Guide