Introduction to Control-M

This chapter includes the following topics:

• INCONTROL Products and IOA

  • IOA

  • INCONTROL

• Functional Approach

  • Main Components

  • Expanded Control-M Functionality

  • Control-M Support for MAINVIEW Batch Optimizer

  • Online User Interface to Control-M

• Control-M Concepts

  • IOA Core and Control-M Repository

  • Date Definition Concepts

  • Date Standards and Date Field Formats

  • Job Ordering and Job Forcing

  • Delaying Job Submission

  • Rerun and Restart

  • Order ID

  • SYSDATA

  • Handling of Jobs

  • Prerequisite Conditions

  • Quantitative and Control Resources

  • Job Priority

  • Automatic Job Flow Adjustment

  • Workload Optimization

INCONTROL Products and IOA

The Control-M 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 mainframes. The INCONTROL family also includes client and server products that facilitate the automation of other platforms.

For more information, see

• IOA

• INCONTROL

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:

Table 1 List of INCONTROL Products

Functional Approach

Control-M automates job processing in your data center.

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

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

• It provides continual data and status information regarding job processing.

Control-M contains many facilities and components. Working together, they automate the data center.

The following topics introduce 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 more minor components that enhance the functionality of Control-M:

• Main Components

• Expanded Control-M Functionality

• Control-M Support for MAINVIEW Batch Optimizer

• Online User Interface to Control-M

Main Components

The following components are essential to Control-M:

• Job Scheduling Definitions

• Active Jobs File

• 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:

Table 2 Job Scheduling Definition Sections

Job scheduling definitions only need be defined once for each job in the production environment. The mechanism used to define job scheduling definitions is discussed in Online Facilities. Once defined, a job scheduling definition is saved. It can be modified later if required, and the changes saved.

Job scheduling definitions are stored in members in partitioned data sets (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 data sets, called scheduling libraries.

• Multiple scheduling libraries can be defined.

Active Jobs File

As mentioned above, 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 Job Ordering and Job Forcing.

Only jobs in the Active Jobs file are candidates for submission by the Control-M monitor.

Control-M Monitor

The Control-M monitor handles and controls job processing:

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

• It monitors the execution of the job.

• It implements post-processing decisions based on instructions in the job scheduling definition and the results of the job execution.

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

Expanded Control-M Functionality

This section describes facilities, features and capabilities of Control-M which supplement the main components of the program.

Automating Job Scheduling: New Day Processing

One of the main purposes of Control-M is to automate job scheduling.

We have already explained that basic scheduling criteria for each job are defined in its job scheduling definition, and that a copy of the job scheduling definition is placed in the Active Jobs file when the basic scheduling criteria are satisfied.

The mechanism used to place job scheduling definitions automatically in the Active Jobs file is called New Day processing.

At a set time each day (defined during installation as the start of day at the site), Control-M performs New Day processing, during which:

• Control-M performs a number of maintenance and cleanup functions that the operator would otherwise have to perform manually.

• Job scheduling definitions are selected from the tables (based on their basic scheduling criteria) and are placed in the Active Jobs file. These jobs can then be submitted and tracked by the Control-M monitor.

The implementation of automated job scheduling and New Day processing, and the components of New Day processing, are discussed in detail in the INCONTROL for z/OS Administrator Guide.

Automatic JCL Update: JCL and AutoEdit Facility

In the production environment, JCL must often be manually modified prior to submission of a job, as in the following cases:

• changing a parameter or a date card

• supplying tape numbers in JCL procedures

• eliminating steps under different run conditions, for example, when end of month processing differs from normal daily run

Manual modification of the JCL is inconvenient at best, and it can be error-prone and lead to serious problems. The JCL and AutoEdit facility offers an automated alternative to manual JCL update.

The JCL and AutoEdit facility permits AutoEdit terms, such as AutoEdit variables, functions, and control statements, to be specified in the JCL in place of values that change from job submission to job submission. AutoEdit terms are prefixed by %%, which distinguishes them from non-AutoEdit terms. For example, the term %%ODAY is recognized as an AutoEdit term.

The values of user-defined variables that have been defined as Sysplex-wide, using the XAE facility, remain both in memory and in a Coupling facility. These values can be used for additional triggering of the same job or other Control-M jobs, in the same computer or in different computers of the same Sysplex.

At time of job submission, AutoEdit terms in the JCL are resolved to their actual values.

The inclusion of AutoEdit terms into the job stream and job scheduling definitions can eliminate the need to change JCL once it is defined. AutoEdit usage can be further simplified and enhanced through the Parameter Prompting facility, which is described in M4: Parameter Prompting Facilities and Parameter Prompting Facilities.

The JCL and the AutoEdit facility is described in detail in JCL and AutoEdit Facility.

Automated Job Submission

Once a job has been placed in the Active Jobs file, the Control-M monitor does not submit the job unless all its runtime scheduling criteria, as defined in the job scheduling definition, are satisfied. Several types of runtime criteria can be defined.

Table 3 Runtime Criteria

Workload Management

Workload Management grants you control over the volume of jobs running in your enterprise and their consumption of resources, without having to change the definitions of individual jobs. This control over job workload is accomplished by applying Workload Policies to groups of jobs. The Workload Policies contain rules that limit the number of running jobs or their resource utilization at any time periods that you choose to schedule.

In addition, you can subject rule enforcement to the dynamic state of load on your systems by associating rules with Load-Indexes, which reflect the load levels on the different LPARS in your systems. For more information, see Workload Optimization.

Use Workload Policies to

• Categorize groups of jobs based on advanced filters

• Limit resources available to these groups of jobs

• Limit the number of jobs that can run concurrently

• Stipulate that certain jobs must run separately from (that is, never run concurrently with) certain other jobs

• Define specific times for these limitations to be applied in the dynamic environment

• Define a minimum threshold load level, based on a Load-Index, for applying the limitations

• Bypass the limitations based on how close jobs are to their DUE IN time

Workload Policies are enforced on active jobs at order time before submission. Modifications of a Workload Policy definition affect the Active Jobs File (AJF) after all Control-M calculations have taken place.

Workload filter

You control which jobs are impacted by defining Workload Policies that include filters based on job attributes. Jobs can be included in more than one Workload Policy, and one Workload Policy can apply to many jobs.

Limiting quantitative resources used by Control-M jobs

Quantitative resources of a Control-M job can be limited so that the job load does not take ownership over all of the resource instances, preventing other jobs from using them. This option is used to balance quantitative resource utilization.

Monitoring of Resources

Three types of runtime criteria require Control-M to monitor the existence of conditions and the availability of resources system-wide. These conditions and resources are mentioned briefly below and are discussed in greater detail in Control-M Concepts:

Table 4 Conditions and Resources

The condition and resource requirements of a job are defined in the job scheduling definition.

Prerequisite conditions are tracked by the IOA Conditions file. Existing and available Quantitative resources and Control resources are tracked by the Control-M Resources file. Prior to version 6.0.00, conditions and resources were stored in a single file, the Conditions/Resources file.

When the prerequisite conditions and resources required by a job are available, the job can be submitted by the monitor, if all other runtime scheduling criteria are satisfied.

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. These situations and problems are detected by analysis of a job sysout.

Notification is issued by the Shout facility, which can send messages to a variety of destinations including the operator console, a TSO user, and the IOA Log file.

Control-M can also be instructed to issue a SHOUT message in the event an exception occurs at time of job submission and/or during job execution, such as when a job completes before, or later than, its anticipated completion time.

History Jobs File

During New Day processing, jobs that have ended OK or whose retention period has expired according to job scheduling definition parameters are deleted from the Active Jobs file.

These jobs can be placed in the History Jobs file during New Day processing. This is an optional feature that can be activated by the INCONTROL administrator. Activation of this feature is described under the HIST parameter in the INCONTROL for z/OS Administrator Guide.

Jobs in the History Jobs file can, by request, be restored to the Active Jobs file, for subsequent restart.

Jobs remain in the History Jobs file until they are deleted according to criteria defined in the job scheduling definition.

The contents of the History Jobs file can be viewed from the History Environment screen, which is described in Online Facilities.

Journaling and Restoration Capability

The Control-M Journal file collects data about changes occurring in the Control-M Active Jobs file, the IOA Conditions file, and the Control-M Resources file during the Control-M working day. This permits forward recovery of the Control-M environment to any time of the day you might choose.

The Journal file is initialized each day during New Day processing. From that point on, for the rest of the working day, the Control-M monitor records in the Journal file all job processing activities that impact the Control-M Active Jobs file, and all prerequisite condition additions to and deletions from the IOA Conditions file and the Control-M Resources file.

If the Control-M Active Jobs file, and optionally the IOA Conditions file and the Control-M Resources file, need to be restored, for example, following a system crash, the CTMRSTR utility can be run to restore the files. The utility uses data from the Journal file to restore the files to the status they had at any specific time after the last run of the New Day procedure.

The Control-M Journal file is initialized each day during New Day processing. Therefore, the time at which the New Day procedure initialized the Journal file is the earliest time to which the Control-M Active Jobs file, the Control-M Resources file, or the IOA Conditions file can be restored.

Journaling and Restoration is an optional feature that can be activated by the INCONTROL administrator. It is described in the INCONTROL for z/OS Administrator Guide. Activation of this feature is described under the JRNL parameter in the INCONTROL for z/OS Installation Guide.

IOA Log Facility

Messages issued by Control-M are written to the IOA Log file. The IOA Log file is a repository for messages issued by all INCONTROL products. Through the IOA Log facility, 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. Post-processing instructions can be defined for virtually any situation, such as job ended successfully, job abended, a particular condition code occurred in a particular step, and so on.

As part of post-processing, Control-M can do the following:

• add a prerequisite condition to, or delete a prerequisite condition from, the IOA Conditions file

• This can trigger or prevent the submission of a job in the Active Jobs file.

• force the placement of a job scheduling definition into the Active Jobs file, regardless of the basic scheduling criteria of the job

• set AutoEdit variables

• send (shout) a specified message to a specified location through the SHOUT facility or by electronic mail

• send a message by mail to the recipient identified by the mail name prefix

• change the final status of a job to OK or NOTOK

• handle the job SYSOUT

• This includes changing its class, deleting it, rerouting it to another node, releasing it for printing, or copying it to another location.

• if Control-M/Analyzer is active, invoke a Control-M/Analyzer rule

• rerun a job

• perform an MVS job restart; for more information, see OUT: Post–processing Parameter

• §Restart§ if Control-M/Restart is active, perform a Control-M/Restart job restart

• §Restart§ if Control-M/Restart is active, automatically archive certain portions of the job output

• stop recycling of cyclic jobs

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. Batch utilities are described in the INCONTROL for z/OS Utilities Guide. Online utilities are described in Online Facilities.

Handling Jobs in the NJE Network

The Control-M monitor handles the control of complex distributed production environments where jobs may be routed for execution to different nodes of the NJE network according to the business needs of the enterprise.

Control-M differentiates between host and remote nodes in the NJE network as follows:

Table 5 NJE Network Nodes

An NJE job is a job submitted by the Control-M monitor for execution on a remote node. Control-M can detect the status of jobs running on a remote node so that once these jobs finish executing, Control-M can assign a status to them.

Handling External Events: CMEM Facility

External events are events in the system that occur outside the control of the Control-M monitor, such as the submission of a job. The Control-M Event Manager (CMEM) facility enables Control-M to respond to and handle such events.

Through rules defined online through the CMEM Rule Definition facility, which is described in Online Facilities, the user specifies actions Control-M must perform in response to external events.

The following types of events are handled by the CMEM facility:

Table 6 Event Types Handled by CMEM

The following actions can be performed by the CMEM facility:

• force one or more Control-M jobs

• For more information, see Job Ordering and Job Forcing.

• add prerequisite conditions to, or delete prerequisite conditions from, the IOA Conditions file and the Control-M Resources file

• stop the job in which the event occurs

• invoke a Control-O rule, if Control-O is active at the site

• send a message to a specified location using the Control-O SHOUT facility, if Control-O is active at the site

• bring under the control of the Control-M monitor a job submitted outside the control of the Control-M monitor, such as a job submitted by a TSO user

• Such a job is called an On Spool job, and the control of On Spool jobs is one of the most important functions of CMEM.      

The CMEM facility, and On Spool jobs, are described in Control-M Event Manager (CMEM).

Using Calendars to Schedule Jobs: IOA Calendar Facility

Specification of scheduling criteria for jobs can be simplified by using calendars. A calendar is a defined schedule that can be applied to jobs, such as Mondays through Fridays in each week in each month.

Calendars are defined in the Calendar facility. Each calendar is assigned a unique name that can be specified in job scheduling definitions. A particular calendar (that is, schedule) need only be defined once.

Specifying the name of a calendar in job scheduling definitions causes that calendar to be used to schedule those jobs.

Three types of calendars can be defined:

• regular

• periodic

• rule-based

Regular Calendars

Regular calendars consist of scheduling dates or days of the week that can be defined according to monthly patterns.

For example

• WEEKDAYS – schedules jobs each Monday through Friday in each month.

• WEEKENDS – schedules jobs on every Saturday and Sunday in each month.

• QUARTERLY – schedules jobs on the last date in each quarter: March31, June30, September30, December31.

Regular calendars are especially useful when many jobs have the same schedule. Defining the schedule once in a calendar, and entering the calendar name in the job scheduling definition of the jobs with that schedule, makes it unnecessary to individually define that schedule in each job scheduling definition.

Periodic Calendars

Periodic calendars are especially useful when scheduling dates do not easily conform to fixed date or day of the week or month patterns.

For example

• PAYCAL – Calendar used for jobs that are scheduled every other Wednesday (such as payroll jobs). Scheduling occurs on the first, third, and (if there is one) fifth Wednesday of some months. Scheduling may occur on the second and fourth Wednesday of other months.

Rule-based Calendars (RBC)

Rule-based calendars schedule jobs, or exclude jobs from being scheduled, according to pre-defined rules and can be referred to from any job definition. RBCs identify the set of scheduling criteria defined in the SMART Table Entity or IOA Calendar Facility that can be used to schedule or exclude the job. This criteria can be applied to any given year.

The IOA Calendar facility is described in Online Facilities.

Accumulating Statistics: Statistics Facility

As part of the post-processing for each job, Control-M determines the elapsed run time of the job. 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. This utility gathers information about the start time of each job, its elapsed run time, CPU utilization time, and so on. The utility places this information in the Statistics file, where averages of these values can be maintained for each job.

Statistics facility averages may be used for several purposes:

• to determine if the execution time of a job falls outside of a statistically normal range of time, which would indicate an execution delay or problem)

• to calculate DUE-IN time for use by the Deadline Scheduling facility, which is discussed under Automatic Job Flow Adjustment

• to determine when a shout message must be issued based on the elapsed time of the job

• to simulate job executions and forecast the impact of changes to the system (described briefly below)

• to determine if a job can complete execution before the Control-M planned shutdown time (QUIESCE command)

Simulating Job Execution and Forecasting Resource Usage: Simulation and Forecasting Facility

Using statistics accumulated by the Statistics facility, the Simulation and Forecasting facility simulates the actions of the Control-M monitor under the conditions specified in simulation parameters.

The Simulation and Forecasting facility enables you to forecast anticipated job load for a specified time in the future, and to forecast the effects of possible changes to the system, such as the impact of:

• removing four tape drives

• increasing CPU power by 30%

• changing the time at which certain jobs are executed

The Simulation and Forecasting facility can improve the efficiency of your site. It can help with resource and configuration decisions, and it can help with the planning of workload scheduling to achieve maximum utilization of resources.

Automatic Tape Adjustment

The Automatic Tape Adjustment facility collects and analyzes statistics regarding tape drive usage, and automatically allocates the appropriate number of tape drives at job order time. This facility, which can be implemented by your INCONTROL administrator, overrides any tape drive Quantitative resource value specified in the job scheduling definition. For more information, see Statistics Screen and RESOURCE: Runtime Scheduling Parameter.

Reporting Facility

Control-M supports a comprehensive reporting facility, which can produce the following types of reports:

Table 7 KSL Report Types

Sample reports are provided in the IOA SAMPLE library. The Reporting facility is described in the KeyStroke Language (KSL) User Guide.

Minus-One Support

Minus-One support is provided as part of Control-M and enhances Parallel Sysplex support (CTMPLEX). With Minus-One support, Control-M users that implement several Control-M monitors in a Sysplex environment can run several installations of Control-M with different maintenance releases or different versions, in parallel. This enables Control-M users to implement installation and upgrade procedures without having to shut down their entire complex.

Minus-One support is available even at sites that are not operating in a Sysplex environment.

WARNING: When upgrading a specific Control-M instance to a new release, you must not utilize features of the new release until all other components (members of the Sysplex, application servers, and so on) are similarly migrated. Doing so may lead to unpredictable results on Control-Ms which have not been migrated.

Control-M interface to the IBM Health Checker

When the Control-M interface to the IBM Health Checker facility is enabled, the Control-M monitor communicates with IBM Health Checker to run appropriate checks to ascertain the status of various Control-M components, subtasks and repositories. The Control-M monitor then alerts the user to any potential Control-M problems via Health Checker reporting facilities. For more information on the IBM Health Checker, see the IBM Health Checker for z/OS User's Guide (for z/OS 1.8 or above).

The following checks are available:

• Job processing delay - reports when one of various Control-M components or subtasks (Submitter, Selector, Spyer) are not responding or experiencing undue delays during job processing.

• Active Jobs File (AJF) status - exception messages are issued when the Control-M AJF utilization threshold has been reached or exceeded.

• CTMPARM synchronization - reports inconsistencies between the values set in the CTMPARM member of the IOA PARM library and the in-memory values of the CTMPARM parameters.

• DORMANT jobs check - exception messages are issued, when one or more jobs are sitting in the Active Jobs file (AJF) for more than the defined number of days.

• Control-M Monitor Virtual Storage Consumption check - alerts you when the amount of available storage below the 16 MB line or above the 16 MB line falls below a certain threshold.

• IOALOG INDEX File Status check - checks the condition of the INDEX file for the IOA Log, and alerts you when the level of correspondence between the INDEX file and the information in the IOA Log falls below a certain threshold percentage.

The Control-M interface to the IBM Health Checker is controlled by parameters set in the CTMPARM member of the IOA PARM library. These parameters specify whether to enable the health checker interface, whether to enable each of the health checks, and the time interval at which the health checks should be run. All of these parameters may be dynamically changed without restarting the Control-M monitor. For more information on setting and modifying these parameters, see the INCONTROL for z/OS Installation Guide.

Control-M Support for MAINVIEW Batch Optimizer

Control-M provides scheduling support for jobs that use pipes at sites that have MAINVIEW Batch Optimizer (MVBO)/Job Optimizer Pipes installed. A pipe is a processor storage buffer that enables data to be passed between applications without using DASD or tape.

MVBO/Job Optimizer Pipes uses pipes to replace sequential job processing with parallel processing wherever feasible. Jobs and job steps normally run sequentially because they depend on data files that become available only after the application that creates them completes execution. When pipes are used, an application does not need to finish running before the data it generates is available to other applications. This significantly reduces I/O operations and delays, and speeds up processing, because pipes enable movement of data using processor storage instead of writing and reading data to and from external storage.

The following topics describe Control-M scheduling support for MVBO/Job Optimizer Pipes:

• Job Scheduling Definition Support

• Enhanced Runtime Scheduling Algorithm

Job Scheduling Definition Support

A PIPE statement can be specified in the Control-M job scheduling definition for each pipe accessed by the job. Each PIPE statement contains the pipe (data set) name. The job scheduling definition of a participant includes a PIPE statement for each pipe accessed by the job.

Enhanced Runtime Scheduling Algorithm

Jobs sharing a pipe are called "pipe participants." Control-M recognizes each set of interrelated pipes and participants as a single, comprehensive unit called a Collection. All pipe participants are submitted concurrently, after verification that all required resources, such as prerequisite conditions or Quantitative resources, are available. This method ensures that participants do not wait for other participants to start executing, for example, at synchronization points.

For more information, see MAINVIEW Batch Optimizer Considerations.

Online User Interface to Control-M

Until now, we have seen how Control-M automates the production environment and we have discussed a number of available facilities that enhance the functionality of Control-M.

However, as mentioned earlier, 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

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-M, and other facilities are shared by many or all products.

All IOA and Control-M online facilities are discussed in detail in Online Facilities. They are all outlined briefly in the following topics:

• Scheduling Definition Facility

• Active Environment (Status) Screen: Online Tracking and Control Facility

• CMEM Rule Definition Facility

• IOA Conditions/Resources Screen

• IOA Log Screen

• IOA Manual Conditions Screen

• IOA Calendar Facility

• Online Utility Screens (Under ISPF)

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

• 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

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

• manually order or force jobs

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. This facility consists of a number of screens, each providing the user with relevant information and options.

The main screen of this facility is the Active Environment screen. (Prior to version 6.0.00, this screen, which displays the status of each job order in the Active Jobs file, was referred to as the Status screen.) All screens and windows available in the Online Tracking and Control facility are accessed through the Active Environment screen. 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 some 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

• §Restart§ view the execution history of all orders of a job, and view the job order sysouts

• view the accumulated statistics of job executions

• 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.

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

• CMEM rules

The user can load rule tables to memory from the CMEM Rule Definition facility. Rule tables can also be loaded to memory by an operator command.

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 conditions or DO COND actions 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, for example, TAPE-ARRIVED

• 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 Manual Conditions list is described in Selected Implementation Issues.

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.

Control-M Concepts

Having discussed Control-M from a functional viewpoint, and having briefly outlined the online user interface to Control-M, it is now worthwhile to examine the following topics that describe important concepts in Control-M functioning:

• IOA Core and Control-M Repository

• Date Definition Concepts

• Date Standards and Date Field Formats

• Job Ordering and Job Forcing

• Rerun and Restart

• Order ID

• SYSDATA

• Handling of Jobs

• Prerequisite Conditions

• Quantitative and Control Resources

• Job Priority

• Automatic Job Flow Adjustment

• Workload Optimization

IOA Core and Control-M Repository

A differentiation is made between files belonging to a particular INCONTROL product such as Control-M, 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 following files:

Table 8 IOA Core Files

Date Definition Concepts

INCONTROL recognizes the following types of date definitions. Depending on the INCONTROL product, either all of them, or some of them, are relevant. All these types are relevant for Control-M:

Table 9 Date Definition Types

Enhanced Definition of ODATE

As of version 6.1.00, ODATE has an enhanced definition. ODATE can also be one of the runtime criteria, such as IN conditions, that must be satisfied before a job can be submitted. Runtime criteria are explained in Automated Job Submission and Monitoring of Resources.

While prior to version 6.1.00 the ODATE was only a VALUE date, it can now be both a RUN date and a VALUE date.

ODATE with the Attribute VALUE

In most cases, ODATE by default has the attribute VALUE. This means that it is a VALUE date, and is not one of the runtime criteria.

When ODATE has the attribute VALUE, it has the following characteristics:

• ODATE is a logical date that is used by Control-M when adding jobs to the Active Jobs file for execution. The ODATE is assigned to a job by manual order or by operation of the New Day procedure.

• The ODATE is a 24hour period. It begins at the New Day time. During the 24hour period that follows that New Day time, all job scheduling is based on the ODATE, which corresponds to the calendar date at that New Day time, rather than the calendar date at the time when the job runs.

• The ODATE can coincide with, precede, or follow the calendar date. If no value is set for the DAYTIMEM parameter in the CTMPARM member, the ODATE coincides with the calendar date. If the DAYTIMEM parameter is set using a - (Minus) sign, the ODATE precedes the calendar date, beginning at the time specified (in 24-hour time format) for the DAYTIMEM parameter. If a + (Plus) sign is used, the ODATE follows the calendar date in a similar manner.

  For more information on the DAYTIMEM parameter, see the description of operational parameters in the Control-M chapter of the INCONTROL for z/OS Installation Guide.

• When a job is eligible to be ordered on an ODATE, it is placed in the Active Jobs file, and is immediately eligible for submission as soon as all its runtime criteria, such as TIME FROM and TIME UNTIL, have been met.

• When the end of the ODATE arrives, the New Day procedure may remove jobs with that ODATE from the Active Jobs file, depending on the setting of the MAXWAIT parameter of the specific job. Jobs removed in this way cease to be eligible for submission.

ODATE with the Attribute RUN

Although by default ODATE has the attribute VALUE, it may also have the attribute RUN, if either set by the user, or the New Day procedure. In such cases, a job can only run when its ODATE is the same as, or after, the Control-M logical date. In other words, the ODATE becomes a runtime criteria.

In this context, runtime criteria are the criteria that determine the eligibility "window" for the submission of the job, that is, the period of time during which the job can be submitted. This eligibility window is determined by the ODATE and the TIME ZONE parameter setting.

For information on changing the attribute of ODATE from VALUE to RUN, see the description of the Time Zone feature in the INCONTROL for z/OS Administrator Guide, and the description of the CTMJOB utility in the INCONTROL for z/OS Utilities Guide.

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 the guide by the following symbols:

Table 10 Gregorian Date Notation

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 definition. However, the format of the 4-character, 6-character or 8-character date depends on the date standard defined during installation.

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

These supported Gregorian date standards are described in the chart below.

Table 11 Supported Gregorian Dates

Julian Dates

Julian dates (also supported by INCONTROL products) are indicated in the guide by the following symbols:

Table 12 Julian Date Notation

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 2001 would be represented in jjj or ddd format as 059, in yyjjj or yyddd format as 01059, and in yyyyjjj or yyyyddd format as 2001059.

Job Ordering and Job Forcing

Job ordering is the placing of a job scheduling definition in the Active Jobs File when the basic scheduling criteria of the job are satisfied.

Most production jobs are automatically ordered during New Day processing. However, jobs can be manually ordered, as well.

Job forcing is the placing of a job scheduling definition in the Active Jobs file regardless of the basic scheduling criteria of the job.

Although any job can be forced, job forcing is generally requested for special purpose, or exception, jobs that are not normally scheduled:

• Jobs can be automatically forced as part of the post-processing of another job. For example, a particular job may be required only if a certain other job abends. In this case, it is forced during the post-processing for the abended job.

• Jobs can also be forced manually. For example, a routine job that is generally ordered automatically according to its scheduling criteria can be manually forced, if required, on a day it is not normally scheduled.

Delaying Job Submission

In certain cases, you may want to delay job submission for some time. For such cases, you can specify an amount of time to keep jobs in WAIT SUBMISSION status using a special AutoEdit variable.

The AutoEdit variable that you use for this purpose is named %%CTM_PRE_SUB_WAIT. You specify this local variable in DO SET or SET VAR statements of a job. Set this variable to one of the following values:

• nnnnS — number of seconds between 0 and 9999

• nnnnM — number of minutes between 0 and 9999

The default is 0, that is, no delay in job submission.

Rerun and Restart

Rerun and restart are two distinct, though related, concepts.

Rerun is the re-execution of a job from the beginning. Job rerun is a Control-M feature.

Restart is the re-execution of a job from a predefined step. Restart is usually performed from the step that failed, although it can be performed from an earlier step, if necessary. Restart utilizes the successful steps from the failed job execution, thereby limiting the amount of processing required to complete successful job execution. This results in lower CPU overhead, and can make a big difference in the timely completion of processing.

A basic MVS restart capability is available, and is described in OUT: Post–processing Parameter. BMC does not recommend this method. This type of restart starts execution of the job from the failed step. However, no auxiliary restart functions are performed.

§Restart§ By contrast, at sites in which Control-M/Restart is installed, restart under Control-M/Restart is available. In addition to performing restart from the desired step, with the capability of automatic step rollback when necessary, Control-M/Restart automatically performs auxiliary restart functions. These include the cataloging and scratching of data sets, prevention of NOT CATLGD 2 errors, and so on.

§Restart§ Instructions for rerun and restart can be defined in the job scheduling definition. Rerun is defined with the DO RERUN statement. Restart is defined with the DO IFRERUN statement. They can be defined to be performed automatically or to be performed upon manual confirmation. For more information, see DO RERUN: Post–processing Parameter, §Restart§DO IFRERUN: Post–processing Parameter, and the Control-M/Restart User Guide. §Restart§

Order ID

Control-M can handle multiple orders of the same job. To distinguish between the job orders, Control-M assigns each job order a unique order ID. Therefore, it is not uncommon to see the same job name with multiple order IDs, each representing a different job order, in the Active Environment screen.

SYSDATA

SYSDATA is the term used to designate the data in three job sysout data sets:

• job log (console messages)

• expanded JCL

• system output messages

SYSDATA data sets are usually produced for each execution of a job or started task. However, not all three data sets are necessarily present in all cases. For example, in JES2, if a job is canceled by the operator before execution, the system output messages data set might not be produced.

For jobs, the output class for this data is defined by one of the following:

• MSGCLASS parameter on the job card, which is added or overwritten by Control-M during job submission

• JCL job-level //OUTPUT statement using the JESDS subparameter

• default values defined in JES initialization parameters

• for started tasks, in JES initialization parameters

When Control-M/Restart is installed, it uses the SYSDATA to analyze the execution of a job order, beginning with the archived SYSDATA of the most recent non-restarted run.

Handling of Jobs

Normally, jobs in a table are processed independently of each other—each job is handled only according to the parameters in its own job scheduling definition.

However, you can define a SMART Table in the Scheduling Definition facility which supports handling the set of jobs in the table as a unit. The scheduling definitions of the jobs as a unit are defined in the SMART Table Entity. Each job in the SMART Table is handled according to the relationship between the basic scheduling criteria of the job and the basic scheduling criteria of the SMART Table Entity. These include:

Table 13 SMART Table Handling Criteria

When jobs are ordered, you will be able to monitor the status of the jobs in and perform actions on the jobs individually. In addition, when a SMART Table is ordered, you will be able to monitor the status of and perform actions on the table. For example, just as you can define post-processing tasks that Control-M should perform when a job successfully ends, you can define post-processing tasks that Control-M should perform when all the jobs in a SMART Table successfully end.

Dynamic SMART Table Insert

When a SMART Table is ordered, some or all of its jobs and the SMART Table Entity are placed in the Active Jobs file. The Dynamic SMART Table Insert facility makes it possible to insert additional jobs into the SMART Table that is already in the Active Jobs File.

The additional jobs must be jobs may be any defined job. If the jobs belong to the SMART Table, they may be either or both of the following:

• jobs that were not scheduled at the current time

• additional copies of jobs that are already in the Active Jobs file

For more information about using the Dynamic SMART Table Insert facility, see the description of the job ordering facility CTMJOB in the Control-M Utilities chapter of the INCONTROL for z/OS Utilities Guide.

Prerequisite Conditions

The prerequisite condition concept is one of the key concepts of Control-M production control.

Prerequisite conditions enable the establishment of job dependencies and, when a job normally requires manual intervention, such as determination that a cartridge arrived on-site, ensures that the manual conditions are satisfied before the job is submitted.

A prerequisite condition is a user-defined, descriptive name given to a certain situation or condition. Prerequisite conditions can be specified in any of three types of statements in a job scheduling definition:

Table 14 Prerequisite Condition Statements

In its most basic form, a prerequisite condition is defined in an IN statement in one job, and as an OUT (or DO COND) statement in another job. This makes the execution of the one job dependent on the execution of the other job.

Job dependencies do not have to be as simple as the above example illustrates. An almost unlimited number of conditions and job dependencies can be created:

• jobs can be dependent on more than one prerequisite condition

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

• the same prerequisite condition can be added by more than one job (caution must be used)

• the same prerequisite condition can be used as an IN condition for more than one job

In SMART Tables (described in Handling of Jobs), prerequisite conditions can be defined as the following SMART Table parameters: IN, OUT and/or DO COND statements. In this case, they apply to the entire set of scheduled jobs.

Prerequisite Condition Dates

IN, OUT, and DO COND statements provide a field for specifying a date to accompany each prerequisite condition. An OUT or DO COND prerequisite condition that is added with a particular date cannot satisfy the same IN prerequisite condition if the IN statement specifies a different date.

Certain Date keywords can be specified in place of, and resolve to, actual date values. For example, keyword ODAT is automatically replaced by the original scheduling date of the job.

Another important keyword for use in place of an actual date is STAT. STAT is used as a date reference for conditions that are static, that is, not date-dependent.

For example, condition IMS_ACTIVE is added when IMS is brought up, and only deleted if IMS is brought down. The date of the condition is irrelevant to jobs requiring that condition. Therefore, this condition would be referenced with a date value of STAT.

Deleting Conditions

The last job to require a particular prerequisite condition, that is, in an IN statement, can also mark that condition for deletion, that is, in an OUT statement. The deletion of unnecessary conditions can serve the following purposes:

It can eliminate unnecessary clutter from the IOA Conditions file and the Control-M Resources file, and the IOA Conditions/Resources screen.

When dependent jobs are scheduled multiple times each day, it can prevent the execution of the earlier scheduled "predecessor" job from incorrectly causing the submission of the later scheduled "successor" job.

Conditions Requiring Manual Intervention

Prerequisite conditions can be used to ensure that a required manual operation has been performed. The following example illustrates such a condition.

Maybe Jobs

In some cases, job dependencies created by prerequisite conditions are desired only if the predecessor jobs are scheduled. If the predecessor jobs are not scheduled, ignore the dependencies.

Such dependencies are called Maybe dependencies, and the unscheduled predecessor jobs that are ignored if they are not scheduled are called Maybe jobs. Conditions set by unscheduled Maybe jobs appear in the Manual Conditions file.

The Manual Conditions file and the handling of Maybe jobs are discussed in Selected Implementation Issues.

Unique Job Flows

A unique job flow feature is used to ensure that, when an entire table is ordered or forced, the new jobs are not effected by conditions that might already exist as relationships between jobs in the AJF. This is accomplished by automatically adding a unique 3-character suffix to the names of any condition that connects jobs within the ordered table. Therefore, the unique suffix is only added to the names of conditions that consist of both the following: 1) an OUT condition of a job in the ordered table and 2) an IN condition to another job in the ordered table.

A typical use case for the unique job flow feature is where the same table is ordered multiple time a day, and there is a need for an independent job flow for each invocation.

Quantitative and Control Resources

To prevent bottlenecks and help guarantee successful execution of jobs, Control-M provides tools to ensure that a job is not submitted for execution until all resources required by the job are available.

Quantitative Resources

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

Control-M maintains a continuously updated status of the Quantitative resources of the site in the Control-M Resources file.

When a Quantitative resource is specified for a job, Control-M determines if a sufficient quantity of the specified resource is available before submitting the job. When the job is submitted, the specified quantity of resource is allocated to that job and is unavailable to other jobs. When the job finishes executing, the resource is made available to other jobs.

The quantity of each resource that is available in the data center is specified using Control-M utilities. An authorized user can dynamically change these quantities manually from the IOA Conditions/Resources screen.

Control Resources

Specification of resource control requirements for a job provides a solution for the problem of resource sharing between different jobs. The mode (Exclusive or Shared) in which a resource is required by a job can be specified.

For example, a job that reads a database without performing updates can access the database in Shared mode; any other job requiring read-only access to the database can access the database at the same time. Conversely, a job that updates the database may require Exclusive control of the database at the time of update such that no other jobs can share the database.

In the example just presented, the database can be defined as a Control resource, and the type of control required by the job (Exclusive or Shared) can be specified for the resource.

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

Job Priority

The job scheduling definition may include a specification of an internal priority for the job. When competing for the same resource, jobs with higher priority take precedence over jobs with lower priority. Users can also assign a "critical path" priority to jobs that must be submitted with the least delay possible. A job with critical path priority is allocated required resources as the resources become available. When all its required resources are available, the job is submitted.

Noncritical jobs are not allocated resources until all required resources are available at the same time.

Automatic Job Flow Adjustment

Predecessor and successor job flows are established through the use of prerequisite conditions that are defined in the job scheduling definition. Successor and predecessor jobs are identified as either "immediate" or "eventual," relative to a specified job:

• An immediate predecessor and successor relationship exists between jobs when one job is directly dependent on prerequisite conditions added by the other job.

• An eventual predecessor and successor relationship exists between jobs if their dependency is indirectly established through a "chain" of immediate predecessor and successor jobs.

From the network of predecessor and successor jobs, critical paths can be identified. A critical path is a chain of jobs that must be executed in their appropriate sequence in order for a specified job to run. A job can have more than one critical path, if different jobs set the same OUT condition, or if a job has OR logic in its IN conditions.

The Job Dependency Network screen, accessed through the Active Environment screen, enables you to view the network of predecessor and successor jobs for a specified job and determine the critical paths for the job.

Although it is prerequisite conditions that define predecessor and successor job relationships, the actual job flow along a critical path can be greatly impacted by the following runtime scheduling criteria in the job scheduling definition:

Table 15 Runtime Scheduling Criteria

In some cases, it might become desirable to adjust the priorities or due out dates and times of certain job orders. For example,

• A high priority successor job is waiting for the submission (and completion) of a lower priority predecessor job.

• A predecessor job cannot terminate early enough for a successor job to terminate by the due out date and time of the successor.

Both types of job flow adjustments can be requested from the Job Dependency Network screen:

• Priority Propagation

  The priority value of each non-Held predecessor and successor job is checked and (if necessary) modified so all jobs in the chain have a priority, and no job has a lower priority than any of its successor jobs.

• Deadline Adjustment

  Starting with the latest eventual successor job in the job flow, the anticipated elapsed time (that is, anticipated execution time) is subtracted from the DUE OUT date and time to determine DUE OUT date and time of the immediate predecessors of that job.

  This process of subtracting elapse times of a job to determine the DUE OUT date and time of the immediate predecessor jobs are repeated until the DUE OUT date and time of the initial or current job is determined.

  • If the user entered an ELAPSE time value in the Online Tracking and Control facility Zoom screen, this value is used for the above calculation.

  • If the user did not enter an ELAPSE time value, the anticipated elapse time is determined by the average runtime taken from the Control-M Statistics file.

Note the following points:

• By subtracting the ELAPSE time of a job from its DUE OUT date and time, the Control-M monitor calculates a DUE IN date and time (that is, the date and time by which the job must be submitted) for each job. The DUE IN time, ELAPSEtime, and DUE OUT time are also displayed in the Job Dependency Network screen.

• The ELAPSE time, DUE OUT date and time, DUE IN date and time, and PRIORITY values for a job are also displayed in the Zoom screen, which is accessed through the Active Environment screen.

• DUE OUT date and time, ELAPSE time and PRIORITY values can also be manually modified in the Zoom screen, but it is recommended that this not be done, and that automatic job flow adjustment be requested instead.

Deadline adjustment will work correctly only if all the jobs have the same time zone, or all the jobs have no time zone.

Workload Optimization

Control-M's Workload Optimization can enable administrators to balance and optimize job runs while taking into account the actual load level of LPARs in real time.

Load-Indexes reflect the load levels on the different LPARs in your systems, based on MSU utilization or 4-Hour Rolling Average (4HRA), as automatically obtained from the LPARs by Control-M. Load levels can also be set by external applications or utilities. In particular, a special type of external Load-Index sets load levels based on MainView Alarms (MVA), as obtained by CMEM or Control-O from BMC AMI Ops Automation.

You can use Workload Optimization to

• Control job execution according to the dynamic workload state, in addition to the other methods of job scheduling and the creation of dependencies between jobs through prerequisite conditions.

• Associate jobs and resources with the dynamic state of LPARs, allowing jobs to run only at appropriate load levels.

• Limit jobs from running at certain times and limit resources from being used by jobs at certain times.

• Limit job runs and the use of resources to time periods when your LPARs are able to accommodate the additional work by associating Load-Index levels with Workload Policies.

• Bypass Workload Policies based on the amount of time left until a job's DUE-IN time, for situations where the Workload Policy might delay an urgent job for too long and not leave it enough time to run.

For more information, see Workload Management and Workload Management Facility.

Load-Indexes Based on MainView Alarms

The Control-M for z/OS Workload Optimization feature gathers z/OS performance metrics sourced from RMF Monitor III and uses these metrics to set internal Load-Indexes. If you do not have access to RMF, you can alternatively use BMC's MainView Alarm Management, part of the BMC AMI Ops Automation suite, as the source for performance metrics.

If you use MainView, you can utilize MainView Alarms as the basis for one type of Load-Indexes in Control-M (alongside the other types of Load-Indexes that you can define in Control-M). These MainView Alarm-based Load-Indexes are automatically set by Control-M whenever an alarm is reported by MainView.

Ongoing monitoring of MainView Alarm-based Load-Indexes by Control-O or CMEM is controlled by the OPTMVLID parameter in the OPTIMIZE section in CTMPARM.

For more information, see Using Load-Indexes in Workload Optimization.

Note that the threshold severity levels of MainView Alarms differ from the threshold levels of Load-Indexes in Control-M. The following table maps MainView threshold values to Control-M threshold values.

Table 15a Prefixing Examples

                   LOAD-INDEX: DYCLIW06
COMMAND ===>                                                    SCROLL===> CRSR
+-----------------------------------------------------------------------------+
|                                                                             |
| Load-Index Name ==> DYCLIW06                                                |
|                                                                             |
| Description ==> MAINVIEW ALARMS WHEN CRITICAL WORK IS AT RISK IN THE LPAR   |
|                                                                             |
| Type        ==> M         (U-Util, 4-4HRA, E-External, M-MainView Alarm)    |
|                                                                             |
|                                                                             |
====== >>>>>>>>>>>>>>>>>>> END OF LOAD-INDEX DETAILS <<<<<<<<<<<<<<<<<<< ======

                        POLICY: LOW_PRIORITY_JOBS
COMMAND ===>                                                    SCROLL===> CRSR
+-----------------------------------------------------------------------------+
|                                                                             |
| WORKLOAD POLICY NAME LOW_PRIORITY_JOBS                STATUS ACTIVE   (A/I) |
|                                                                             |
| =========================================================================== |
| POLICY FILTER (UPDATED ON 28.02.22 13:14 BY USER U05B     )                 |
| =========================================================================== |
| MEMNAME                                                                     |
| APPL      REP*                                                              |
| GROUP                                                                       |
| SCHED TAB                                                                   |
| APPL TYPE                                                                   |
| SCHENV                                                                      |
| =========================================================================== |
| POLICY RULES  (UPDATED ON 28.02.22 13:14 BY USER U05B     )                 |
| =========================================================================== |
| R U L E   T Y P E S:    |  P E R I O D  T Y P E S:                          |
|                         |                                                   |
| R - RESOURCE LIMIT      |  1 - DAYS                   4 - WEEK DAYS RANGE   |
| J - JOBS LIMIT          |  2 - BETWEEN DATES          5 - SPECIFIC DATES    |
|                         |  3 - BETWEEN DATES AND TIME 6 - ADVANCED SCHED    |
| =========================================================================== |
| RULE TYPE JOB                    PERIOD TYPE 1 - Days                       |
| DESCRIPTION DELAY LOW-PRIORITY JOBS WHEN CRITICAL WORK IS AT RISK           |
| LIMIT 0000 WHEN LOAD-INDEX DYCLIW06             AT LEVEL CRITICAL AND ABOVE |
| BYPASS LIMIT FOR JOBS WITH     MINUTES OR LESS BEFORE DUE IN                |
| ON WEEKDAYS ALL                         (OR ALL)                            |
|        EACH DAY, FROM TIME      UNTIL TIME                      (HH:MM)     |
| =========================================================================== |
| RULE TYPE JOB                    PERIOD TYPE 1 - Days                       |
| DESCRIPTION LIMIT LOW-PRIORITY JOBS WHEN CRITICAL WORK IS AT RISK           |
| LIMIT 0010 WHEN LOAD-INDEX DYCLIW06             AT LEVEL HIGH     AND ABOVE |
| BYPASS LIMIT FOR JOBS WITH     MINUTES OR LESS BEFORE DUE IN                |
| ON WEEKDAYS ALL                         (OR ALL)                            |
|        EACH DAY, FROM TIME      UNTIL TIME                      (HH:MM)     |
| =========================================================================== |
| RULE TYPE                        PERIOD TYPE   (1-6 or ? for selection)     |
| =========================================================================== |
====== >>>>>>>>>>>>>>>>>>>> END OF POLICY DEFINITION <<<<<<<<<<<<<<<<<<<< =====