Job Production Parameters

This chapter includes the following topics:

• Overview for Job Scheduling Definitions

• Parameter Descriptions for Job Scheduling Definitions

• ADJUST CONDITIONS: General Job Parameter

• APPL: General Job Parameter

• APPL FORM: General Job Parameter

• APPL TYPE: General Job Parameter

• APPL VER: General Job Parameter

• §Restart§ AUTO-ARCHIVE: Post–processing Parameter

• CAPTURE BY: Post–processing Parameter

• CM VER: General Job Parameter

• CONFCAL: Basic Scheduling Parameter

• CONFIRM: Runtime Scheduling Parameter

• CONTROL: Runtime Scheduling Parameter

• CTB STEP: General Job Parameter

• CYCLIC TYPE: Runtime Scheduling Parameter

• D-CAT: Basic Scheduling Parameter

• DATES: Basic Scheduling Parameter

• DAYS: Basic Scheduling Parameter

• DEFINITION ACTIVE: Basic Scheduling Parameter

• DESC: General Job Parameter

• DO Statement: Post–processing Parameter

• DO COND: Post–processing Parameter

• DO CTBRULE: Post–processing Parameter

• DO FORCEJOB: Post–processing Parameter

• §Restart§DO IFRERUN: Post–processing Parameter

• DO MAIL: Post–processing Parameter

• DO NOTOK: Post–processing Parameter

• DO OK: Post–processing Parameter

• DO REMEDY: Post–processing Parameter

• DO REMFORCE: Post–processing Parameter

• DO RERUN: Post–processing Parameter

• DO SET: Post–processing Parameter

• DO SHOUT: Post–processing Parameter

• DO STOPCYCL: Post-Processing Parameter

• DO SYSOUT: Post-Processing Parameter

• DOC: General Job Parameter

• DOCLIB: General Job Parameter

• DOCMEM: General Job Parameter

• DUE OUT: Runtime Scheduling Parameter

• END-TABLE: Post–processing Parameter

• GROUP: General Job Parameter

• IN: Runtime Scheduling Parameter

• INSTREAM JCL: General Job Parameter

• INTERVAL: Post–processing Parameter

• INTERVAL SEQUENCE: Runtime Scheduling Parameter

• KEEP AT LEAST ## DAYS AFTER ENDED NOT OK: Post-Processing Parameter

• KEEP JOBS UNTIL REMOVED: Post-Processing Parameter

• MAXRERUN: Post–processing Parameter

• MAXWAIT: Basic Scheduling Parameter

• MEMLIB: General Job Parameter

• MEMNAME: General Job Parameter

• MINIMUM: Basic Scheduling Parameter

• MONTHS: Basic Scheduling Parameter

• NJE NODE: General Job Parameter

• ON Statements: Post–processing Parameter

• ON PGMST: Post–processing Parameter

• ON SYSOUT: Post–processing Parameter

• ON TABLE-END: Post–processing Parameter

• ON VAR: Post–processing Parameter

• OUT: Post–processing Parameter

• OVERLIB: General Job Parameter

• OWNER: General Job Parameter

• PDS: Basic Scheduling Parameter

• PIPE: General Job Parameter

• §Restart§PREVENT-NCT2: General Job Parameter

• PRIORITY: Runtime Scheduling Parameter

• RELATIONSHIP: Basic Scheduling Parameter

• RERUNMEM: Post–processing Parameter

• RESOURCE: Runtime Scheduling Parameter

• RETENTION: # OF DAYS TO KEEP: Post–processing Parameter

• RETENTION: # OF GENERATIONS TO KEEP: Post–processing Parameter

• RETRO: Basic Scheduling Parameter

• SAC: Run Time Parameter

• SCHEDULE RBC: Basic Scheduling Parameter

• SCHEDULE RBC ACTIVE: Basic Scheduling Parameter

• SCHENV: General Job Parameter

• SET VAR: General Job Parameter

• SHOUT: Post–processing Parameter

• SPECIFIC TIMES: Runtime Scheduling Parameter

• STAT CAL: General Job Parameter

• Step Name: +EVERY

• SYSOUT: Post–processing Parameter

• SYSTEM ID: General Job Parameter

• TABLE: General Job Parameter

• TASKTYPE: General Job Parameter

• TBL MAXWAIT: Basic Scheduling Parameter

• TIME + DAYS: Runtime Scheduling Parameter

• TIME ZONE: Runtime Scheduling Parameter

• WDAYS: Basic Scheduling Parameter

Overview for Job Scheduling Definitions

Job scheduling definitions consist of parameters that correspond to the decisions made and actions performed when handling the scheduling, submission, and post-processing of a job. Job scheduling definitions are defined in the Job Scheduling Definition screen, which is the main screen of the Scheduling Definition facility.

Figure 139 Job Scheduling Definition Screen

JOB: BACKPL02 LIB CTM.PROD.SCHEDULE                       TABLE: BACKUP
COMMAND ===>                                            SCROLL===> CRSR
  OWNER   M44         TASKTYPE JOB    PREVENT-NCT2 Y DFLT  N           
  SCHENV                         SYSTEM ID                NJE NODE     
  SET VAR                                                              
  CTB STEP AT         NAME            TYPE                             
  DOCMEM  BACKPL02    DOCLIB   CTM.PROD.DOC                            
  =====================================================================
  SCHEDULE RBC                                                         
  RELATIONSHIP (AND/OR) O                                              
  DAYS                                                          DCAL   
                                                                AND/OR 
  WDAYS                                                         WCAL   
 MONTHS  1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y 
  DATES                                                                
  CONFCAL WORKDAYS SHIFT       RETRO N MAXWAIT 04  D-CAT               
  MINIMUM          PDS                                                 
  DEFINITION ACTIVE FROM          UNTIL                                
  =====================================================================
  IN       START-DAILY-BACKUP   ODAT                                   
  CONTROL                                                              
  RESOURCE INIT                 0001      CART                 0001    
  PIPE     CTM.PROD.PIPE                                               
  FROM TIME         +     DAYS    UNTIL TIME      +     DAYS           
  DUE OUT TIME      +     DAYS    PRIORITY     SAC    CONFIRM          
  TIME ZONE:                                                           
  =====================================================================
  OUT      BAKCKPL02-ENDED-OK   ODAT +                                 
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS         
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP          
  SYSOUT OP   (C,D,F,N,R)                                         FROM 
  MAXRERUN     RERUNMEM                              INTERVAL  FROM    
  STEP RANGE         FR (PGM.PROC)          .            TO      .     
  ON PGMST          PROCST          CODES                          A/O 
    DO                                                                 
  ON SYSOUT                                     FROM 001 TO 132    A/O 
    DO                                                                 
  ON VAR                                                       
    DO                                                          
  SHOUT WHEN          TIME       +     DAYS      TO             URGN   
    MS                                                                 
  =====================================================================
  APPL TYPE                                  APPL VER                  
  APPL FORM                                  CM   VER                  
  INSTREAM JCL: N                                                      
                                                                       
 ======= >>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<< ====
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                            19.17.13

In a SMART Table, a SMART Table Entity (shown in Figure 140) must be defined before the job scheduling definitions.

Figure 140 SMART Table Entity Definition Screen

TBL ACCOUNTS_GROUP       CTM.PROD.SCHEDULE(TBL)
COMMAND ===>                                                 SCROLL===> CRSR
+--------------------------------------------------------------------------+
  GROUP   ACCOUNTS_GROUP          MEMNAME  ACCOUNTS                         
  OWNER   N04B                                                              
  APPL                                                                      
  DESC                                                                      
  ADJUST CONDITIONS N             TBL MAXWAIT 00        STAT CAL            
  KEEP JOBS UNTIL REMOVED Y       KEEP AT LEAST 05 DAYS AFTER ENDED NOT OK  
  SET VAR                                                                   
  DOCMEM  ACCOUNTS    DOCLIB   CTM.PROD.DOC                                 
  ==========================================================================
  SCHEDULE RBC CTM_LEVEL_RBC                               LEVEL CTM
  ==========================================================================
  SCHEDULE RBC ALL_DAYS                                   LEVEL TBL         
  DAYS    ALL                                                   DCAL        
                                                                     AND/OR 
  WDAYS                                                         WCAL        
  MONTHS  1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y    
  DATES                                                                     
  CONFCAL          SHIFT        RETRO N MAXWAIT 00                          
  SCHEDULE RBC ACTIVE FROM           UNTIL                                  
  ==========================================================================
  SCHEDULE RBC TBL_LEVEL_RBC                                  LEVEL TBL     
  DAYS                                                          DCAL        
                                                                     AND/OR 
  WDAYS                                                         WCAL        
  MONTHS  1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y    
  DATES                                                                     
  CONFCAL          SHIFT        RETRO N MAXWAIT 00                          
  SCHEDULE RBC ACTIVE FROM           UNTIL                                  
  ==========================================================================
  IN                                                                        
  CONTROL                                                                   
  FROM TIME         +     DAYS    UNTIL TIME      +     DAYS                
  DUE OUT TIME      +     DAYS    PRIORITY     SAC    CONFIRM               
  TIME ZONE:                                                                
  ==========================================================================
  OUT                                                                       
  ON TABLE-END NOTOK                                                        
    DO COND          ACCTS-CHK-REQUIRED   ODAT +                            
  ON VAR                                                                
    DO    
  SHOUT WHEN           TIME       +     DAYS     TO                  URGN   
    MS                                                                      
======= >>>>>>>>>>>>>>>>>>>> END OF GROUP PARAMETERS <<<<<<<<<<<<<<<< ======
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                 19.17.13

Most parameters in the SMART Table Entity definition are the same as in the job scheduling definition, but they apply to the SMART Table as a whole. Therefore:

• At least one set of basic scheduling criteria in the SMART Table Entity must be satisfied before any job in the SMART Table can be scheduled.

• Runtime scheduling criteria in the SMART Table Entity must be satisfied before any job in the SMART Table can be executed.

• Post-processing statements in the SMART Table Entity are applied only after all jobs in the SMART Table have finished executing.

The following parameters in the SMART Table Entity are not found in the job scheduling definition:

• ADJUST CONDITIONS

• ON TABLE-END

• SCHEDULE RBC ACTIVE FROM and UNTIL

Usage and operation of the Scheduling Definition facility, including entry and exit of the Job Scheduling Definition screen, is described in the INCONTROL for z/OS Utilities Guide.

In addition to defining jobs through the Scheduling Definition facility, jobs can also be defined using the batch utility CTMBLT, described in the INCONTROL for z/OS Utilities Guide, or using the online utility QUICKDEF. The QUICKDEF utility, the Quick Schedule Definition facility, is available under ISPF only. For more information about it, see M5: Quick Schedule Definition.

This chapter provides a detailed description of the job scheduling definition parameters and statements.

The parameters of the Job Scheduling Definition screen are divided into the following categories:

• General parameters

• Basic Scheduling parameters

• Runtime Scheduling parameters

• Post-processing parameters

A brief summary of the parameters in each category is provided on the following pages. This is followed by a detailed description of each parameter, in alphabetical order.

General Parameters for Job Scheduling Definitions: Summary

General parameters provide general information about the job and certain information required by the JCL. Information about the following parameters is provided in this chapter:

Table 156 General Parameters

Basic Scheduling Parameters for Job Scheduling Definitions: Summary

Basic Scheduling parameters determine if the job is a candidate for execution on a specific date. If a job is a candidate for execution on a specific date, a job order is automatically placed in the Active Jobs file during New Day processing.

Each job order placed in the Active Jobs file is associated with an original scheduling date. This is the date the job is to run according to the Basic Scheduling parameters. This date is not necessarily the same as the current system date or the current working date. For further information, see Date Definition Concepts.

Basic Scheduling parameters and subparameters allow different methods of expressing a job schedule.

Each set of basic scheduling criteria in the SMART Table Entity must be uniquely labeled by a SCHEDULE RBC value. At least one Schedule RBC must be defined.

In job scheduling definitions, SCHEDULE RBC is optional. Each specified SCHEDULE RBC value in the job scheduling definition for a job of a SMART table must match a SCHEDULE RBC value in the SMART Table Entity.

To specify an Exclude RBC, an exclamation mark (!) must be added as a prefix when defining a Table level RBC, or as a prefix to the RBC name when referring to a Control-M (CTM) level RBC.

The RELATIONSHIP parameter appears in job scheduling definitions in both SMART Tables and non-SMART tables.

The RELATIONSHIP parameter defines the relationship (AND/OR) between rule-based calendar criteria and the basic scheduling criteria of the job, that is, whether one or both sets of criteria are to be satisfied.

The Basic Scheduling parameters, except SCHEDULE RBC and RELATIONSHIP, are listed below by category. When defining basic scheduling criteria for jobs in tables, or when defining basic scheduling criteria for SMART Table Entities, the following rules apply to these categories of parameters:

• Parameters must be selected from one and only one of the first three categories (A, B, or C).

• Parameters in the last two categories (D and E) are optional.

Table 157 Category A, B, C, and D Parameters

Category C Parameters

Schedule the job if the number of free tracks in the specified partitioned data set (PDS) is less than the minimum number of tracks specified. This set of criteria is intended for jobs or started tasks that clean, compress or enlarge libraries or that issue warning messages if the minimum number of free tracks is not available.

Basic Scheduling Parameters for Job Scheduling Definitions

Each Basic Scheduling parameter is described in this chapter. However, the interrelationships between some of these parameters are described briefly below.

DAYS, DCAL, WDAYS, WCAL

These parameters are all optional.

The DAYS parameter identifies days of the month on which the job must be scheduled, such as first day of the month, third working day of the month. Several formats are available for specifying DAYS values.

The WDAYS parameter identifies days of the week on which the job must be scheduled, such as the first day of the week, the second day of each week, and so on. Several formats are available for specifying WDAYS values.

A calendar name can be specified in the DCAL and/or WCAL fields. A calendar specifies days of the year on which a rule can be scheduled, known as working days. For more information on calendars and the IOA Calendar facility, see IOA Calendar Facility.

When both the DAYS and DCAL parameters are specified, they work as a complementary unit, as described in DAYS: Basic Scheduling Parameter. Similarly, when both WDAYS and WCAL are specified, they also work as a complementary unit, as described in WDAYS: Basic Scheduling Parameter.

When values for both DAYS (/DCAL) and WDAYS (/WCAL) are specified in the same job scheduling definition, the resulting schedule is determined by the value specified in field AND/OR.

CONFCAL and SHIFT

A calendar specified in CONFCAL is not used for job scheduling, but is used instead for validating a scheduled date. Only jobs that have satisfied all other specified basic scheduling criteria are checked against the CONFCAL calendar. If the day is a working day in the CONFCAL calendar, the job is scheduled on that day. Otherwise, the job is either shifted to (scheduled on) another day according to the value entered in the SHIFT parameter, or the job is not scheduled (if no SHIFT value has been specified).

CONFCAL calendars are especially useful for handling holidays and other scheduling exceptions.

Defining a Schedule – Internal Scheduling Logic

When defining tables which handle jobs to be scheduled individually, it is useful to understand the IOA Scheduling facility logic, which determines whether to order a job on a specific day. This logic is described below.

1. ACTIVE FROM and UNTIL parameters are checked first. If the current date falls outside the time range specified, no further checking is performed.

2. DAYS and DCAL parameters are checked independently and a first tentative scheduling decision is created.

3. WDAYS and WCAL parameters are checked independently and a second tentative scheduling decision is created.

4. A third tentative scheduling decision is created based on the above two decisions and the AND/OR value linking them.

   (If DAYS and/or DCAL are not specified, this third temporary scheduling decision is identical to the second scheduling decision. If WDAYS and/or WCAL are not specified, this third scheduling decision is identical to the first scheduling decision.

5. If CONFCAL and/or SHIFT are specified, this third scheduling decision is adjusted according to the CONFCAL and SHIFT criteria.

6. This third scheduling decision (as adjusted) becomes the final scheduling decision. The IOA Scheduling facility determines whether to schedule a job based on this final scheduling decision.

Scheduling Jobs in SMART Tables

The following scheduling algorithm applies to SMART Tables:

1. Before jobs in a SMART Table can be scheduled, the SMART Table itself must be eligible for scheduling (that is, at least one of the rule-based calendars of basic scheduling criteria in the SMART Table Entity has been satisfied).

2. If (and only if) the SMART Table is eligible for scheduling, each job scheduling definition in the table is individually checked for possible scheduling.

3. For each job scheduling definition:

   • Rule-based calendars in the job scheduling definition are checked sequentially beginning with the first calendar. The SCHEDULE RBC ACTIVE FROM and UNTIL parameters are checked first. If the current date falls outside the time range specified, no further checking is performed.

     If the criteria of a rule-based calendar is satisfied, no further checks are performed on the remaining calendars. The criteria belonging to the satisfied calendar are used in the scheduling algorithm.

   • The RELATIONSHIP parameter (AND/OR) is checked.

     • If a rule-based calendar is satisfied and the defined relationship is OR, the satisfied rule-based calendar is sufficient and the job is scheduled according to criteria of this calendar. No further checks are performed.

     • If no rule-based calendar is satisfied and the defined relationship is AND (that is, the job requires that the rule-based calendar be satisfied), the job is not scheduled if it is in a SMART Table. If it is in a non-SMART table it is scheduled according to the job scheduling definition.

     • If a rule-based calendar is satisfied and the defined relationship is AND, or if no rule-based calendar was satisfied and the defined relationship is OR, the basic scheduling criteria of the job must be satisfied (that is, the algorithm continues with the next step).

   • The basic scheduling criteria of the job are checked.

     • If the basic scheduling criteria of the job are not satisfied, the job is not scheduled.

     • If the basic scheduling criteria of the job are satisfied, the job is scheduled.

The basic scheduling criteria of the job, not the rule-based calendar criteria, are used for scheduling. This is a concern only if there are conflicting MAXWAIT values in the rule-based calendar criteria and the basic scheduling criteria of the job. In this case, the MAXWAIT value from the basic scheduling criteria of the job is used.

Figure 141 SMART Table Scheduling Flowchart

Runtime Scheduling Parameters for Job Scheduling Definitions: Summary

Runtime Scheduling parameters define job submission criteria. The job is not submitted unless all submission criteria are satisfied. The following criteria can be defined:

Table 158 Runtime Scheduling Parameter Criteria

Post-Processing Parameters for Job Scheduling Definitions: Summary

Actions to be performed after job execution generally depend on the results of the job execution:

• Certain actions may be required when the job ends successfully.

• Certain actions may be required when the job fails, depending on the reason for failure.

• Certain actions may be required in any and all situations.

The Control-M monitor tracks each job execution. Following the termination of a job, the Control-M monitor checks the execution results of each step in the job. Based on the results, the Control-M monitor determines a final status of the job. Either of two final job statuses can be assigned:

Table 159 Final Job Statuses

Control-M assigns an end status to jobs based on the following criteria:

• If Control-M extracts the JOBRC value from z/OS or JES, and DO OK/NOTOK actions are not defined in the ON PGMSTEP statements of step(s), it sets the job end status after comparing the value to the MAXCCOK. The MAXCCOK (Maximum Completion Code Considered as Successful) installation parameter is specified in the CTMPARM member. When JOBRC is higher than MAXCCOK, Control-M sets the job status as ended NOTOK. When JOBRC is not higher than MAXCCOK, Control-M sets the job status as ended OK.

• Even if Control-M extracts the JOBRC and sets the job end status according to MAXCCOK, the job end status can be changed by the DO OK/NOTOK actions defined in the ON PGMSTEP +JOBRC statement. For more information, see Job completion code: +JOBRC.

• If Control-M does not extract the JOBRC value, and DO OK/NOTOK actions are not defined in the ON PGMSTEP statements of step(s), it sets the job end status based on the value the MAXRC. The MAXRC (Maximum Completion Code) is the highest return code of any step in the job, or if the job fails because of an ABEND, the last ABEND code. When MAXRC is higher than MAXCCOK, Control-M sets the job status as ended NOTOK. When MAXRC is not higher than MAXCCOK, Control-M sets the job status as ended OK.

• Whether or not JOBRC is extracted by Control-M, the job end status can be changed by DO OK/NOTOK actions defined in the ON PGMSTEP statements of step(s).

If a post-processing error occurs after a job ends OK (including FORCE OK), it indicates that there is a problem with the post-processing statements defined in the job scheduling definition. For example, a post-processing statement may have indicated an action that the owner of the job was not authorized to perform.

Post-processing parameters can be divided into the following groups:

Parameters Performed When the Job Ends OK

Table 160 Parameters Performed When the Job Ends OK

Conditional Processing or Processing in All Situations

Most conditional processing is specified through a combination of ON and DO statements. ON and DO statement definition consists of defining ON statement step and code events (for example, ON PGMST STEP1 CODE C0016), followed by DO statement actions (for example, DO SHOUT, DO FORCEJOB), which are performed when the ON step and code criteria are satisfied.

A range of steps for use in the ON statement can be defined in the STEP RANGE parameter.

ON and DO statements also specify actions that are to be performed in any and all cases. To ensure that the ON statement is activated for all step and code events, enter reserved word ANYSTEP as the ON step name and ***** as the ON code.

Table 161 Conditional Processing Statements

Rerun and Cyclic Post-processing Parameters

Table 162 Rerun and Cyclic Post-Processing Parameters

SMART Table Entity Post-processing Parameters

Table 163 SMART Table Entity Post-Processing Parameters

General IOA Features

General IOA features include:

• Customization

• Environment Support

• Terminal Support

• Special Character Usage on Terminals

• Color Support

• Prefixing

• Character Masking

Parameter Descriptions for Job Scheduling Definitions

The following pages contain detailed descriptions of all parameters available in the Control-M Job Definition screen. Parameters are arranged in alphabetical order. Within each parameter, subparameters are arranged according to the order of the fields on the screen.

Each parameter begins on a new page, including:

• A brief explanation of the purpose of the parameter.

• The format required for defining the parameter within an extract of the Control-M screen.

• General information explaining the parameter and its usage.

• Where applicable, some practical examples illustrating implementation of the parameter.

For more information on the Job Definition facility, see Online Facilities.

ADJUST CONDITIONS: General Job Parameter

Determines how Control-M handles a requirement for a prerequisite condition by successor jobs in a SMART Table. This parameter appears in the SMART Table Entity only and applies only to SMART Tables.

Figure 142 ADJUST CONDITIONS Parameter Format

DESC
ADJUST CONDITIONS               TBL MAXWAIT      STAT CAL
KEEP JOBS UNTIL REMOVED      KEEP AT LEAST    DAYS AFTER ENDED NOT OK
SET VAR

(Optional) Valid values are shown in Table 164.

Table 164 ADJUST CONDITIONS Parameter Values

General Information for ADJUST CONDITIONS

This parameter is applied to all jobs in the SMART Table. It provides the options shown in Table 164 when job dependency is defined between jobs in a SMART Table by their respective conditions.

Such a job dependency arises when one job in a SMART Table is dependent on a condition that is triggered by another job in the SMART Table. If the triggering job is not ordered, meaning, placed on the Active Jobs file, because the scheduling criteria of the triggering job do not match the current Odate, the dependent job cannot run.

The options provided by the ADJUST CONDITIONS parameter enable you to avoid this difficulty.

ADJUST CONDITIONS Set to Yes

If you enter the value Y for the ADJUST CONDITIONS parameter, the following principles apply:

• Control-M erases IN conditions from each job in the SMART Table that is placed on the AJF. The following criteria must be met before an IN condition is erased:

  • The IN condition in the job is triggered by a predecessor job.

  • The scheduling criteria of the predecessor job are such that the predecessor job will not be ordered during the current day.

  The erasing of these IN conditions frees the successor job from its dependency on the predecessor job.

• Only the image of the job on the AJF is affected. The original job scheduling definition remains unchanged.

• The erased condition does not appear in the Zoom screen.

ADJUST CONDITIONS Set to No

If you enter the value N for the ADJUST CONDITIONS parameter, the following principles apply:

• Control-M runs normally.

• You must release any jobs that are likely to wait indefinitely on the AJF because they are dependent on predecessor jobs with scheduling criteria such that they will not be ordered. To release the dependent jobs, use one of the manual options, such as those available in

  • the IOA Conditions/Resources screen (Screen 4)

  • the IOA Manual Conditions file (Screen 7)

ADJUST CONDITIONS Set to Dummy

If you enter the value D for the ADJUST CONDITIONS parameter, the following principles apply:

• Control-M places all the jobs in the SMART Table onto the AJF when the SMART Table is ordered.

• Jobs in the SMART Table with scheduling criteria that fit the current ODATE remain unchanged.

• Jobs in the SMART Table with scheduling criteria that do not fit the current ODATE, and would not ordinarily be ordered, are placed on the AJF as DUMMY jobs (the MEMLIB parameter is changed to DUMMY). This permits the original logical flow of the SMART Table to be maintained by preserving the relationships of the IN and OUT conditions of these dummy jobs.

• Only the image of the job on the AJF is affected. The original job scheduling definition remains unchanged.

ADJUST CONDITIONS Set to Bridge

If you enter the value B for the ADJUST CONDITIONS parameter, the following principles apply:

• Control-M bridges over jobs in the SMART Table that have scheduling criteria that do not fit the current ODATE, and would not ordinarily be ordered. This permits the original logical flow of the SMART Table.

  If a scheduled job contains an IN condition that should be inherited from an unscheduled predecessor job, this condition is replaced by the IN conditions of the unscheduled predecessor job.

• Conditions that are deleted by an unscheduled (bridged over) job are handled as follows:

  • If the deleted condition is used only once in the SMART Table as an IN condition, the job that inherits the IN condition also inherits the delete action.

  • If the deleted condition is used by more than one scheduled job in the SMART Table, the delete action is performed by the SMART Table (when the table completes), to avoid premature deletion.

• In certain scenarios the SMART Table is ordered without applying a bridge, based on the following principles:

  • A bridge is not applied to jobs that contain complex IN conditions, such as conditions with OR, Not, or parentheses.

  • If more than one job adds the same OUT condition, this is considered an implicit OR and the jobs are not bridged.

    If there are two job flows A and B, which connect to job C with the same OUT condition E1, it is considered an implicit OR, as job C can wait for E1 either from job flow A OR job flow B.

• Conditions that were defined using AutoEdit variables are resolved based on the values of the original job before the bridge is applied.

• Messages from the Bridge action appear in the job log or SMART Table log.

  You can control the level of detail of the messages using the ADJBCMSG parameter in the CTMPARM member in the IOA PARM library.

Examples for ADJUST CONDITIONS

APPL: General Job Parameter

Descriptive name of the application to which the group of the job belongs. Used as a common descriptive name for a set of related groups (of jobs).

Figure 144 APPL Parameter Format

APPL specifies an application name of 1 through 20 characters. Only trailing blanks are allowed.

By default, the APPL parameter is optional. It can be modified in the user profile.

General Information for APPL

The parameter facilitates the handling of groups of production jobs.

Example for APPL

JOB: OPERCOMP LIB CTM.PROD.SCHEDULE                        TABLE: OPER
COMMAND ===>                                           SCROLL===> CRSR
+--------------------------------------------------------------------+
  MEMNAME OPERCOMP    MEMLIB   GENERAL                                
  OWNER   M44         TASKTYPE JOB    PREVENT-NCT2 Y DFLT  N          
  APPL    OPER                        GROUP MAINTENANCE               
  DESC    JOB RUN ON THE 1ST OF THE MONTH                             
  OVERLIB                                                   STAT CAL  
  SCHENV                         SYSTEM ID                  NJE NODE  
  SET VAR                                                             
  CTB STEP AT         NAME            TYPE                            
  DOCMEM  OPERCOMP    DOCLIB   CTM.PROD.DOC                           
  ====================================================================
  DAYS    01                                                    DCAL  
                                                               AND/OR 
  WDAYS                                                         WCAL  
  MONTHS 1-Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
  DATES                                                               
  CONFCAL          SHIFT       RETRO Y MAXWAIT 00  D-CAT              
  MINIMUM          PDS                                                
  DEFINITION ACTIVE FROM          UNTIL                               
  ====================================================================
  IN                                                                  
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                           16.44.00

APPL FORM: General Job Parameter

The type of form used for entering application data.

This is a protected field whose value is obtained from Control-M/EM. Reserved for future use.

Figure 146 APPL FORM Parameter Format

APPL TYPE: General Job Parameter

The application that runs the job.

This is a protected field whose value is obtained from Control-M/EM. Reserved for future use.

Figure 147 APPL TYPE Parameter Format

APPL VER: General Job Parameter

The version of the application on which the job runs.

This is a protected field whose value is obtained from Control-M/EM. Reserved for future use.

Figure 148 APPL VER Parameter Format

§Restart§ AUTO-ARCHIVE: Post–processing Parameter

Controls SYSDATA archiving.

Figure 149 §Restart§ AUTO-ARCHIVE Parameter Format

(Optional) The AUTO-ARCHIVE parameter consists of the subparameters described in Table 165.

Table 165 §Restart§ AUTO-ARCHIVE Subparameter Format

General Information for AUTO-ARCHIVE

The AUTO-ARCHIVE subparameter allows you to decide whether to archive SYSDATA, which is defined in SYSDATA. While archiving SYSDATA is normally desirable, it might not be desirable for cyclic jobs, started tasks, or frequently repeated jobs that do not require restart.

If archiving, the SYSDB subparameter allows you to decide whether SYSDATA for different jobs must be archived to a common data set (Y) or whether to use a separate data set for each run (N). If Y is entered, a single archived SYSDATA data set is used for archiving until it is full. Then, another SYSDATA data set is allocated and used. This is the recommended method.

Creating a separate data set for each run is not recommended because:

• Creating many data sets consumes a large amount of space in the disk VTOC.

• Each data set is allocated on a track basis. If the SYSDATA does not completely fill the track, large amounts of disk space may be wasted.

The MAXDAYS and MAXRUNS subparameters define retention criteria for the archived SYSDATA of jobs that ended NOTOK. Defaults are defined in the Control-M/Restart installation parameters. You can specify either or both parameters to override the defaults. If both parameters are specified, retention is limited by the condition that is fulfilled first.

When archiving SYSDATA, BMC recommends that you do not enter the value 99 in the MAXWAIT parameter for cyclic jobs or started tasks. Otherwise, these jobs, which are never automatically deleted from the Active Jobs file, may cause the disk to fill up with unnecessary archived SYSDATA. The MAXWAIT parameter is described in MAXWAIT: Basic Scheduling Parameter.

AUTO-ARCHIVE and the History File

SYSDATA is archived in the History Jobs file, as defined by the values set for the MAXDAYS and MAXRUNS parameters, and under the following conditions:

As long as a job exists either in the AJF or in the History Jobs file, the action of the MAXDAYS and MAXRUNS parameters applies to the job's SYSDATA, except for the last archived SYSDATA, which will be retained regardless of the setting of the MAXDAYS and MAXRUNS parameters. On the other hand, if the HIST parameter in the CTMPARM member in the IOA PARM library is set to N (No) and a job is deleted from the AJF, the job's SYSDATA is deleted regardless of the values set for the MAXDAYS and MAXRUNS parameters. For more information, see information about maintaining previous runs in the History Jobs file in the Control-M/Restart User Guide.

Example for AUTO-ARCHIVE

 JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE                     TABLE: PRODKPL 
 COMMAND ===>                                           SCROLL===> CRSR
 +--------------------------------------------------------------------+
   ====================================================================
   OUT                                                                 
   AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS  07  MAXRUNS  020   
   RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP         
   SYSOUT OP   (C,D,F,N,R)                                         FROM 
   MAXRERUN     RERUNMEM                            INTERVAL    FROM  
   STEP RANGE         FR (PGM.PROC)          .          TO       .     
   ON PGMST          PROCST          CODES                          A/O 
     DO                                                                
   ON SYSOUT                                     FROM 001 TO 132    A/O 
     DO                                                                
   ON VAR                                                              
     DO                                                                
   SHOUT WHEN           TIME       +     DAYS     TO              URGN 
     MS                                                                
 ======= >>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<< =====
                                                                       
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                            16.44.00

CAPTURE BY: Post–processing Parameter

Extracts data from the job's JES output datasets (JESYSMSG, JESJCL, and JESMSGLG), and places the data into a Control-M AutoEdit variable.

Figure 151 CAPTURE BY Parameter Format

 ===========================================================================
  OUT                                                                        
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS               
  RETENTION:  # OF DAYS TO KEEP      # OF GENERATIONS TO KEEP                
  SYSOUT OP   (C,D,F,N,R)                                              FROM  
  MAXRERUN      RERUNMEM                                                     
  CAPTURE BY   (W - WORD / C - CHAR)                                         
  CYCLIC TYPE: C                                   INTERVAL         FROM     
  INTERVAL SEQUENCE: +         +         +         +         +               
  SPECIFIC TIMES:                                             TOLERANCE      
                       +           +           +           +           +     
  STEP RANGE         FR (PGM.PROC)          .          TO          .         
  ON PGMST          PROCST          CODES                               A/O  

(Optional) The CAPTURE BY parameter consists of the subparameters described in Table 166.

Table 166 CAPTURE BY Subparameter Format

General Information for CAPTURE BY

The CAPTURE BY parameter defines the job capture definitions. The capture feature provides a convenient method for extracting data from a job's JES output datasets (JESYSMSG, JESJCL, and JESMSGLG) and sharing the data between jobs. This parameter can be used to search the output of a job for specified text and based on the capture parameters, extract words or characters from the output. The destination of the capture is a Control-M user-defined AutoEdit variable that can be set to any of the following types:

• Local: Defines variables that can be used by other post-processing actions of this job, such as messages, DO action arguments, or a rerun (manual or cyclic) of the job.

• Global: Defines a variable in the IOA Global Variable data base which enables variable sharing between different jobs.

• Pool: Defines variables in a pool. The variable is referenced by the pool name - %%\\<pool_name>\<variable_name>.

  A pool is a collection of variables that can be referenced by name, from any job that is currently active. Using the capabilities of setting variable values at order time and using local variables for the pool names allows the user to pass pre-defined pool names to the jobs at order time or to set values of variables in a pool to be used by the ordered jobs. For more information, see Pool Variables.

• Smart Table: Enables other jobs in the table to access the specified variable either in the job during the job run, or in post-processing.

• System variables are not allowed.

User-defined variables can be used to

• Store intermediate values in a series of variable parameters

• Store information to be included in a SHOUT or DO MAIL e-mail message or in a DO REMFORCE variable value.

Global variables can be used to pass information between jobs. For example, job A can set global variable %%A to Yes, and job B can reset %%A to No in response. Global variables can also be created and modified using the IOAGLV utility. For more information about this utility, see the INCONTROL for z/OS Utilities Guide.

Resolution of each user variable depends on the specified prefix, and the scope of the specified variable. Each of these concepts is described below.

Syntax for CAPTURE BY

Syntax requirements for user-defined variables are described in User-Defined Variables.

Scope for CAPTURE BY

The scope of a variable is the extent to which it is available to other jobs. Each variable can be

• local for a specific job

• common to all jobs in a SMART Table

• global for all jobs

Multiple Capture statements in a job definition can specify the same variable name. In such a case, the last processed capture determines the value placed into the variable.

Control M uses the following logic to determine which value to use when a variable is specified in a job processing definition:

• Control M checks if a local variable (for the job) has been defined with the specified name. If a local variable exists, the value specified for that variable is used.

• If no local variable exists with the specified name, and the job is in a SMART Table, Control M checks for a variable with the specified name in the SMART Table definition. If the variable is defined in the SMART Table definition, that value is used.

• If a SMART Table variable is specified, but the job is not in a SMART Table, or the variable is not defined in the SMART Table definition, an error is produced.

For more information, see JCL and AutoEdit Facility.

Examples for CAPTURE BY

======================================================================
OUT      JOB2-OK              1801 +                                  
AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS          
RETENTION:  # OF DAYS TO KEEP      # OF GENERATIONS TO KEEP           
SYSOUT OP   (C,D,F,N,R)                                         FROM  
MAXRERUN      RERUNMEM                                                
CAPTURE BY W (W - WORD / C - CHAR)                                    
       SEARCH SUBMITTED                                               
       SKIP 00000004 ROWS                                             
       SKIP 002 WORDS       DELIMITER _                               
       TAKE 07  WORDS                                                 
     INTO %%VAR_A                                                     
CAPTURE BY   (W - WORD / C - CHAR)                                    
CYCLIC TYPE: C                                 INTERVAL       FROM    

29 APR 2015 JOB EXECUTION DATE
         19 CARDS READ
        681 SYSOUT PRINT RECORDS
          0 SYSOUT PUNCH RECORDS
         37 SYSOUT SPOOL KBYTES
       0.10 MINUTES EXECUTION TIME
      1 //N27ASMCL JOB ,ASM,TIME=NOLIMIT,REGION=0M,MSGLEVEL=(1,1), 
        //         USER=N27,
        //         CLASS=A,
        //       MSGCLASS=X
        //*---- SUBMITTED BY CONTROL-M (FROM MEMLIB)      ODATE=150429
        //*---- SCHEDULE CTMP.V900.OPR.SCHEDULE(REGJOB)
        //*---- SCHEDULED DUE TO RBC:  !NORBC
        //*---- JCL      N27.LIB.CNTL(RUNTEST3)
        //*---- CONTROL-M JOB IDENTIFICATION: ORDER ID=00020 RUN NO. =00001
        //*JOBFROM N27
      2 //         JCLLIB ORDER=IOAP.V900.PROCLIB
      3 //         INCLUDE MEMBER=IOASET
        XX*************************************************************

 ======================================================================
 OUT      JOB2-OK              1801 +                                  
 AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS          
 RETENTION:  # OF DAYS TO KEEP      # OF GENERATIONS TO KEEP           
 SYSOUT OP   (C,D,F,N,R)                                         FROM  
 MAXRERUN      RERUNMEM                                                
 CAPTURE BY C (W – WORD / C – CHAR)                                    
        SEARCH SUBMITTED                                               
        SKIP 00000004 ROWS                                             
        SKIP 018 CHARS                                                 
        TAKE 49  CHARS  (EMPTY \ ZEROS - TILL END OF THE LINE)         
      INTO %%VAR_B                                                     
 CAPTURE BY   (W - WORD / C - CHAR)                                    
 CYCLIC TYPE: C                                  INTERVAL        FROM  

CM VER: General Job Parameter

The version number of the Control Module (CM) that is used to run the job.

This is a protected field whose value is obtained from Control-M/EM. Reserved for future use.

Figure 154 CM VER Parameter Format

CONFCAL: Basic Scheduling Parameter

Specifies the calendar name that is used to confirm the job scheduling.

Related parameters are DAYS: Basic Scheduling Parameter, WDAYS: Basic Scheduling Parameter, and DATES: Basic Scheduling Parameter.

Figure 155 CONFCAL Parameter Format

(Optional) The following table describes CONFCAL subparameters.

Table 167 Optional CONFCAL Subparameters

General Information for CONFCAL

CONFCAL calendars are useful for handling holidays and other scheduling exceptions.

CONFCAL is optional. If no value is set for the CONFCAL parameter, jobs are scheduled according to other basic scheduling criteria without confirmation.

CONFCAL must not contain the name of a periodic calendar. If it does, no day can pass the confirmation.

CONFCAL cannot be used with the PDS and MINIMUM parameters.

SHIFT Subparameter

If no CONFCAL calendar is specified, no value can be entered in the SHIFT subparameter, and this field has no effect on job scheduling.

The format and valid values of the SHIFT subparameter are described in Table 167 Optional CONFCAL Subparameters.

The interaction between the x value and the yyy value of the SHIFT subparameter is as follows:

• If the original scheduling day of the job is a working day in the CONFCAL calendar, the x value is ignored and the yyy value determines when the job is scheduled.

• If the original scheduling day of the job is not a working day in the CONFCAL calendar, job scheduling is shifted according to the x value and then shifted again according to the yyy value (if specified) to determine when the job is scheduled.

• If the original scheduling day is not a working day and the x value is blank, the job is not scheduled (regardless of whether a yyy value is specified).

Shifts are not applied to 'negative' scheduling days, such as -n, -Dn, or -Ln. However, if the result of shifting is a day that is not allowed (negative), the job is shifted again to the next allowed working day (for a forward shift) or to the previous allowed working day (for a backward shift).

Examples for CONFCAL

DAYS      1,7,15
AND/OR    AND
WDAYS     6
CONFCAL   WORKDAYS
SHIFT     >

WDAYS     6
CONFCAL   WORKDAYS
SHIFT     <-01

CONFIRM: Runtime Scheduling Parameter

Ensures manual confirmation before a job is submitted or a group is made active.

Figure 157 CONFIRM Parameter Format

(Optional) Valid values are described in Table 168.

Table 168 Optional CONFIRM Parameter Values

General Information for CONFIRM

If CONFIRM is set to Y, the job appears in the Active Environment screen with a WAIT CONFIRMATION (FOR SCHEDULE) status. Option C (Confirm) must then be entered in the Active Environment screen for the job to be submitted. When the job is confirmed in the Active Environment screen, the CONFIRM value in the Zoom screen changes to N. If CONFIRM is set to N or left blank, the job is automatically submitted by Control-M at the first available opportunity.

Example for CONFIRM

JOB: OPERCOMP LIB CTM.PROD.SCHEDULE                        TABLE: OPER
COMMAND ===>                                            SCROLL===> CRSR
+---------------------------------------------------------------------+
  SCHENV                         SYSTEM ID                  NJE NODE   
  SET VAR                                                              
  CTB STEP AT         NAME            TYPE                             
  DOCMEM  OPERCOMP    DOCLIB   CTM.PROD.DOC                            
  =====================================================================
SCHEDULE RBC                                                           
RELATIONSHIP (AND/OR) O                                                
DAYS                                                       DCAL        
                                                              AND/OR   
WDAYS                                                      WCAL        
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y 
DATES                                                                  
CONFCAL          SHIFT       RETRO N MAXWAIT 04   D-CAT                
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
  =================================================================
  IN                                                                   
  CONTROL                                                              
  RESOURCE INIT                 0001                                   
  PIPE                                                                 
  FROM TIME         +     DAYS    UNTIL TIME      +     DAYS  
  DUE OUT TIME      +     DAYS    PRIORITY     SAC    CONFIRM Y
  TIME ZONE:                                                           
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                            11.17.00

CONTROL: Runtime Scheduling Parameter

Ensures exclusive or shared control over runtime resources.

Figure 159 CONTROL Parameter Format

(Optional) A maximum of two resources can be specified in each CONTROL line. Upon specifying the second resource in a CONTROL line and pressing Enter, a new line is opened (for specifying additional resources).

Each CONTROL specification consists of the mandatory subparameters described in Table 169 and may include the optional subparameter described in Table 170.

Table 169 Mandatory CONTROL Subparameters

Table 170 Optional CONTROL Subparameter

CONTROL DISK-VS0020 E K

General Information for CONTROL

The CONTROL parameter is used to control parallel execution of jobs.

If a job requires a resource in exclusive state, it cannot share usage of that resource with another job (that is, the jobs cannot run in parallel). For example:

• If JOBA requires exclusive control of a resource that is already in use by a different job, JOBA must wait until the other job frees the resource regardless of whether the other job is using the resource in shared or exclusive state.

• If JOBA already has exclusive control of a resource, any job requiring that resource must wait until JOBA frees the resource, regardless of whether the job requires the resource in shared or exclusive state.

If a job requires a resource in shared state, that job can run in parallel with other jobs requiring the same resource in shared state. For example:

• If JOBA requires shared control of a resource that is already in shared use by different jobs, JOBA can use that resource at the same time.

• If JOBA already has shared control of a resource, any job requiring that same resource in shared state can use that resource at the same time.

However:

• If JOBA requires shared control of a resource that is already in exclusive use by a different job, JOBA must wait until the other job frees the resource.

• If JOBA already has shared control of a resource, any job requiring that same resource in exclusive state must wait until JOBA frees the resource.

For more information, see Quantitative and Control Resources.

Example for CONTROL

The following three screens (job scheduling definitions) indicate how the CONTROL parameter can control resource usage. All three job scheduling definitions require resource (disk) DISK-VS0020:

• The first job, BKPVS020, is a backup job that requires exclusive control of disk DISK-VS0020.

• The other two jobs, CMPRSJOB and CMPRSSRC, are both compress jobs. They do not require exclusive control (that is, they can share control) of disk DISK-VS0020.

The result is as follows:

• The CMPRSJOB and CMPRSSRC jobs can be run in parallel with each other, but neither can run in parallel with the BKPUS020 job.

• If the BKPVS020 job is running, the CMPRSJOB and CMPRSSRC jobs must wait.

• If either the CMPRSJOB job or the CMPRSSRC job is running, the BKPVS020 job must wait.

JOB: BKPVS020 LIB CTM.PROD.SCHEDULE                      TABLE: BACKUP
COMMAND ===>                                           SCROLL===> CRSR
+--------------------------------------------------------------------+
  OVERLIB                                               STAT CAL      
  SCHENV                         SYSTEM ID              NJE NODE       
  SET VAR                                                              
  CTB STEP AT         NAME            TYPE                             
  DOCMEM  BKPVS020    DOCLIB   CTM.PROD.DOC                            
  ====================================================================
SCHEDULE RBC                                                           
RELATIONSHIP (AND/OR) O                                                
DAYS                                                       DCAL        
                                                              AND/OR   
WDAYS                                                      WCAL        
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y  
DATES                                                                  
CONFCAL          SHIFT       RETRO N MAXWAIT 04   D-CAT                
MINIMUM PDS
DEFINITION ACTIVE FROM UNTIL
  ====================================================================
  IN                                                                   
  CONTROL  DISK-VS0020          E                               
  RESOURCE                                                             
  FROM TIME         +     DAYS    UNTIL TIME      +     DAYS           
  DUE OUT TIME      +     DAYS    PRIORITY     SAC    CONFIRM          
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                           11.17.00

JOB: CMPRSSCR LIB CTM.PROD.SCHEDULE                      TABLE: OPMAINT
COMMAND ===>                                            SCROLL===> CRSR
+---------------------------------------------------------------------+
  OVERLIB                                               STAT CAL       
  SCHENV                         SYSTEM ID              NJE NODE       
  SET VAR                                                              
  CTB STEP AT         NAME            TYPE                             
  DOCMEM  CMPRSSCR    DOCLIB   CTM.PROD.DOC                            
  =====================================================================
SCHEDULE RBC                                                           
RELATIONSHIP (AND/OR) O                                                
DAYS                                                      DCAL         
                                                              AND/OR   
WDAYS                                                     WCAL         
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y  
DATES                                                                  
CONFCAL          SHIFT       RETRO N MAXWAIT 04   D-CAT                
MINIMUM 025      PDS   GSD.DEPO.SCR
DEFINITION ACTIVE FROM UNTIL
  =====================================================================
  IN                                                                   
  CONTROL  DISK-VS0020          S                                 
  RESOURCE                                                             
  FROM TIME         +     DAYS    UNTIL TIME      +     DAYS           
  DUE OUT TIME      +     DAYS    PRIORITY     SAC    CONFIRM          
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                            11.17.00

JOB: CMPRSJOB LIB CTM.PROD.SCHEDULE                      TABLE: OPMAINT
COMMAND ===>                                            SCROLL===> CRSR
+---------------------------------------------------------------------+
  OVERLIB                                                 STAT CAL     
  SCHENV                         SYSTEM ID                NJE NODE    
  SET VAR                                                              
  CTB STEP AT         NAME            TYPE                             
  DOCMEM  CMPRSJOB    DOCLIB   CTM.PROD.DOC                            
  =====================================================================
SCHEDULE RBC                                                           
RELATIONSHIP (AND/OR) O                                                
DAYS                                                         DCAL      
                                                              AND/OR   
WDAYS                                                        WCAL      
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y 
DATES                                                                 
CONFCAL          SHIFT       RETRO N MAXWAIT 04   D-CAT                
MINIMUM  PDS  
DEFINITION ACTIVE FROM UNTIL
  =====================================================================
  IN                                                                   
  CONTROL DISK-VS0020           S                                
  RESOURCE                                                             
  FROM TIME         +     DAYS    UNTIL TIME      +     DAYS           
  DUE OUT TIME      +     DAYS    PRIORITY     SAC    CONFIRM          
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                            11.17.00

CTB STEP: General Job Parameter

Adds Control-M/Analyzer steps as the first and/or last step of the execution of the job.

Figure 163 CTB STEP Parameter Format

(Optional) The CTB STEP parameter consists of the subparameters described in Table 171.

Table 171 Optional CTB STEP Parameters

General Information for CTB STEP

A maximum of two CTB STEP statements (that is, one START statement and one END statement) can be entered.

Upon filling in the first CTB STEP line on the screen and pressing Enter, the ARGUMENTS line and the second CTB STEP line are displayed. If the second CTB STEP line is filled in and Enter is pressed, its ARGUMENTS line is displayed.

Multiple arguments must be separated by a comma without a space because they are automatically passed to the Control-M/Analyzer step as a PARM=‘arguments’ parameter in the JCL of the step.

Control-M uses the status returned by Control-M/Analyzer as it would use the return status of any job step.

• If Control-M/Analyzer returns a status of OK or TOLER (within accepted tolerances), Control-M considers the step as having ended OK.

• If Control-M/Analyzer returns a status of NOTOK or ABEND, Control-M considers the job step as having ended NOTOK.

Example for CTB STEP

JOB: SACALC01  LIB CTM.PROD.SCHEDULE                     TABLE: SALARY
COMMAND ===>                                            SCROLL===> CRSR
+---------------------------------------------------------------------+
  MEMNAME SACALC01    MEMLIB   GENERAL                                 
  OWNER   SYS1        TASKTYPE JOB    PREVENT-NCT2   DFLT  N           
  APPL    SAL                         GROUP SALARY                     
  DESC    SALARY CALCULATIONS                                          
  OVERLIB                                                 STAT CAL     
  SCHENV                         SYSTEM ID                NJE NODE     
  SET VAR                                                             
  CTB STEP AT END     NAME CHKCALC    TYPE RULE                 
    ARGUMENTS %%ODATE                                           
  CTB STEP AT         NAME            TYPE                             
  DOCMEM  SACALC01    DOCLIB   CTM.PROD.DOC                            
  =====================================================================
SCHEDULE RBC                                                           
RELATIONSHIP (AND/OR) O                                                
DAYS 0.15                                                   DCAL       
                                                              AND/OR   
WDAYS                                                       WCAL       
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y  
DATES                                                                  
CONFCAL          SHIFT       RETRO N MAXWAIT 04   D-CAT                
MINIMUM  PDS  
DEFINITION ACTIVE FROM UNTIL
  =====================================================================
  IN                                                                  
  CONTROL                                                             
  RESOURCE                                                            
  PIPE                                                                 
  FROM TIME         +     DAYS    UNTIL TIME      +     DAYS  
  DUE OUT TIME      +     DAYS    PRIORITY     SAC    CONFIRM 
  TIME ZONE:                                                           
  =====================================================================
  OUT      SALARY-OK            ODAT +                         
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                            11.17.00

CYCLIC TYPE: Runtime Scheduling Parameter

This parameter defines whether the enhanced cyclic feature will be used. This field exists in both the Job Scheduling and SMART Table Entity Definition Screens. The parameter can have one of the following values:

• C - The enhanced cyclic feature is not used. Default.

• V - Varying interval sequence

• S - Run at specific times

In order for the V or S options to be specified, in the Job Scheduling Definition, the TASKTYPE parameter must be set to CYC; in the SMART Table Entity Definition the TASKTYPE parameter must be set to TBC.

Figure 165 CYCLIC TYPE Parameter Format

TIME ZONE:  =====================================================================
OUT  (L) JOB1-ENDED-OK                                         ODAT +  
                                                                       
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS         
  RETENTION:  # OF DAYS TO KEEP      # OF GENERATIONS TO KEEP          
  SYSOUT OP   (C,D,F,N,R)                                         FROM 
  MAXRERUN      RERUNMEM                                               
  CYCLIC TYPE: C                                   INTERVAL    FROM    
  INTERVAL SEQUENCE: +         +         +         +         +         
  SPECIFIC TIMES:                                          TOLERANCE  
                       +           +           +           +        +  
  STEP RANGE         FR (PGM.PROC)          .          TO        .     
  ON PGMST          PROCST          CODES                           A/O 

For details on the meaning and usage of the S and V options, see SPECIFIC TIMES: Runtime Scheduling Parameter and INTERVAL SEQUENCE: Runtime Scheduling Parameter.

D-CAT: Basic Scheduling Parameter

Name of a Control-D report decollating mission category that must be scheduled under Control-D when the job is scheduled under Control-M.

Figure 166 DCAT Parameter Format

(Optional) The D-CAT parameter must be 1 through 20 characters, or * for all categories.

If this parameter is specified when Control-D is not installed, New Day processing stops immediately after this job. For a description of New Day processing, see Selected Implementation Issues, and the INCONTROL for z/OS Administrator Guide.

General Information for D-CAT

If the parameter is specified, whenever the job is scheduled, a search is made in the Control-D report decollating mission library for a job (member) with the name entered in the MEMNAME parameter, which is described in MEMNAME: General Job Parameter, and with the same category. (No search is made in the case of job restarts.)

Generally, the selected category is forced and placed in the Control-D Active Missions file (that is, the output of the job must be decollated by Control-D). If D-CAT is set to *, all categories of the job are forced under Control-D.

Example for D-CAT

 JOB: GNRLDR12 LIB CTM.PROD.SCHEDULE                     TABLE: GNRLDR
 COMMAND ===>                                          SCROLL===> CRSR
 +-------------------------------------------------------------------+
   MEMNAME GNRLDR12    MEMLIB   GENERAL                               
   OWNER   SYS1        TASKTYPE JOB    PREVENT-NCT2   DFLT  N         
   APPL    GENERAL                     GROUP GENERAL-LEDGER           
   DESC    GENERAL LEDGER DAILY REPORTS                               
   OVERLIB                                                 STAT CAL   
   SCHENV                         SYSTEM ID                NJE NODE   
   SET VAR                                                            
   CTB STEP AT         NAME            TYPE                           
   DOCMEM  GNRLDR12    DOCLIB   CTM.PROD.DOC                          
   ===================================================================
SCHEDULE RBC                                                          
RELATIONSHIP (AND/OR) O                                               
DAYS                                                         DCAL     
                                                             AND/OR   
WDAYS                                                        WCAL     
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y 
DATES                                                                 
CONFCAL          SHIFT       RETRO N MAXWAIT 00 D-CAT DAILY           
MINIMUM PDS 
DEFINITION ACTIVE FROM UNTIL
   ===================================================================
   IN                                                                 
  COMMANDS: EDIT, DOC, PLAN, JOBSTAT                          11.17.00

DATES: Basic Scheduling Parameter

Specifies dates, by month and day, on which the job must be scheduled for execution.

Figure 168 DATES Parameter Format

(Optional) The DATES parameter specifies a valid 4-character date, in either mmdd or ddmm format, depending on site format.

A maximum of 12 dates can be specified.

General Information for DATES

The job is scheduled for execution only on the dates specified in the DATES parameter.

The DATES parameter cannot be used with the PDS, MINIMUM, DAYS, and DCAL parameters.

If values are set for both the MONTHS parameter and the DATES parameter, the MONTHS parameter setting is ignored.

To specify more than 12 dates for one job, define the dates in a calendar (instead of using this parameter) and specify the calendar in the DCAL (or WCAL) subparameter.

As an alternative to using calendars for specifying more than twelve dates in jobs belonging to a group, up to twelve dates can be specified in a Schedule RBC definition in the SMART Table Entity, and multiple rule-based calendars of this type can be defined. These can then be specified in the jobs.

The relationship between DATES and WDAYS and WCAL is OR. If the job is to be scheduled according to the DATES parameter or according to the WDAYS and WCAL combination, it is scheduled.

Examples for DATES

DATES 0115

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE                    TABLE: PRODKPL
COMMAND ===>                                          SCROLL===> CRSR
+-------------------------------------------------------------------+
  MEMNAME PRDKPL01    MEMLIB   CTM.PROD.JCL                          
  OWNER   SYS1        TASKTYPE JOB    PREVENT-NCT2   DFLT  N         
  APPL    KPL                         GROUP PROD-KPL                 
  DESC    DAILY PRODUCTION - START OF APPL-PROD-KPL                  
  OVERLIB                                                 STAT CAL   
  SCHENV                         SYSTEM ID                NJE NODE   
  SET VAR                                                            
  CTB STEP AT         NAME            TYPE                           
  DOCMEM  PRDKPL01    DOCLIB   CTM.PROD.DOC                          
  ===================================================================
SCHEDULE RBC                                                         
RELATIONSHIP (AND/OR) O                                              
DAYS                                                         DCAL    
                                                             AND/OR  
WDAYS                                                        WCAL    
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES 2106 2112                                                      
CONFCAL          SHIFT       RETRO N MAXWAIT 04   D-CAT              
MINIMUM    PDS  
DEFINITION ACTIVE FROM UNTIL
  ===================================================================
  IN       START-DAILY-PROD-KPL ODAT                                 
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                          11.17.00

DAYS: Basic Scheduling Parameter

The days of the month on which the job must be scheduled.

Related parameters are WDAYS: Basic Scheduling Parameter and CONFCAL: Basic Scheduling Parameter.

Figure 170 DAYS Parameter Format

(Optional) The DAYS parameter specifies days of the month on which the job must be scheduled, provided other basic scheduling criteria are met. Values for DAYS can be specified alone, or they can be specified together with a calendar specified in the DCAL subparameter. DAYS and DCAL can also be specified together with WDAYS and WCAL (described under WDAYS: Basic Scheduling Parameter).

The DAYS subparameters are described in Table 172.

Table 172 DAYS Subparameters

Assuming all other basic scheduling criteria are met:

• When DAYS are specified without DCAL, the job is scheduled on the specified days (in the specified months).

• When DCAL is specified without DAYS, the job is scheduled on all working days marked in the DCAL calendar.

• When DAYS and DCAL are both specified, scheduling depends on how the working days are defined in the calendar and the values or format of the DAYS parameter combine, as described in the following paragraphs.

• When both DAYS and WDAYS criteria are specified, scheduling depends on the AND/OR subparameter connecting them.

Valid Formats for DAYS

Valid formats for the DAYS parameter, and how they relate to DCAL, are described in the following paragraphs.

In the following non-periodic scheduling formats:

• n is an integer from 1 through 31.

• Multiple values can be specified (separated by commas) in any order.

• A calendar name specified for DCAL must not designate a periodic calendar.

Table 173 Non-Periodic Scheduling Formats

In the following periodic scheduling formats:

• n is any integer from 1 through 63, and i is any valid period identifier.

• An * can be specified as the i value to represent all periods.

• An * can be specified as the n value in format DnPi to represent all days. (* is not a valid n value in formats –DnPi, LnPi and –LnPi.)

• A period can span any number of days, but by default, no more than 33 days can elapse after the appearance of one identifier in a period until the appearance of the next matching identifier in the same period. Once a gap of 33 days has been reached, the period automatically closes. However, the INCONTROL administrator can change the 33-day default by changing the value in member IOADFLT in the IOAENV library.

• The name of a periodic calendar must be specified in DCAL. For details about periodic calendars, see IOA Calendar Facility.

Table 174 Periodic Scheduling Formats

General Information for DAYS

Negative values take precedence over positive values when determining whether a job must be scheduled on a certain date. If a negative value (that is, format –n, –Dn, –Ln, –DnPi, or – LnPi) in either the DAYS or WDAYS field prevents a job from being scheduled on a date, the job is not scheduled on that date even if a positive value (such as Ln) in a basic scheduling parameter would otherwise result in the job being scheduled on that date.   

A maximum of eight periodic values of type DnPi, –DnPi, LnPi, and/or –LnPi can be designated in any desired order.

If periodic and non-periodic values are mixed when specifying the DAYS parameter, processing depends on the calendar type specified in the DCAL parameter:

• If a non-periodic calendar is specified in the DCAL parameter, only non-periodic values in the DAYS parameter are processed; periodic values are ignored. In this case, negative periodic values (that is, –DnPi, –LnPi) are also ignored and do not supersede other values.

• If a periodic calendar is specified in the DCAL parameter, all periodic values and the negative non-periodic value -n in the DAYS parameter are processed; all other non-periodic values are ignored.

The MONTHS parameter is ignored when periodic values are specified in the DAYS parameter.

For information about certain exceptional situations in the interaction of the DAYS and MONTHS parameters, see MONTHS: Basic Scheduling Parameter.

The DAYS parameter cannot be used with the PDS, MINIMUM, and DATES parameters.

Examples for DAYS

The examples in this chapter are based on the following assumptions:

• The current month is December, 2001.

• Working days are defined in calendar WORKDAYS, which contains the following working days (indicated by Y) for December, 2001.

  Copy

  ---S-------------S-------------S-------------S-------------S---
   1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1
       Y Y Y Y Y     Y Y Y Y Y     Y Y Y Y Y     Y   Y Y Y     Y

• WDAYS are defined as working days beginning on Monday.

• Periodic calendar PERIDAYS contains the following periodic definition for December 2001. These examples assume that all other days of this calendar are blank.

  Copy

  ---S-------------S-------------S-------------S-------------S---
   1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 + 1
       B C A A B     B C A A B     B C A A B     B C A A B     B

• Start of the week is defined as Monday. Weeks start on the following dates in December 2001: 3rd, 10th, 17th, 24th, and 31st.

At the end of each example, asterisks in a December 2001 calendar indicate the days on which the job is scheduled.

DAYS     17,L1

DAYS     +1,-6
DCAL     WORKDAYS

DAYS     -D1,-17,-L1
DCAL     WORKDAYS

DAYS     <8
DCAL     WORKDAYS

DAYS    -5,D1PA,-D2PB
DCAL    PERIDAYS

DAYS     1
AND/OR   OR
WDAYS    1

DAYS     3
AND/OR   AND
WDAYS    1

DAYS     L1,L2,L3,L4,L5,L6,L7
AND/OR   AND
WDAYS    1

DAYS     1,7,15
AND/OR   AND
WDAYS    6
CONFCAL  WORKDAYS
SHIFT    >

DAYS     16,17,18,19,20,21,22
AND/OR   AND
WDAYS    5

DEFINITION ACTIVE: Basic Scheduling Parameter

Specifies the time limits (FROM, UNTIL) for using the job scheduling definition.

Figure 181 DEFINITION ACTIVE Parameter Format

(Optional) The parameters include the subparameters described in Table 175.

Table 175 DEFINITION ACTIVE Subparameters

The format of either the FROM or UNTIL subparameters may be ddmmyy, mmddyy, or yymmdd, depending on your local site standard, as set by the DATETYP parameter in the IOAPARM member in the IOA PARM library.

General Information for DEFINITION ACTIVE

FROM and UNTIL dates together define a time frame for ordering the job. Unless forced, a job can only be ordered during the specified time frame. However, if the job is forced, the FROM and UNTIL parameters are ignored.

• If you specify both the FROM and UNTIL subparameters for a particular job, the job can only be ordered on or later than the date specified in the FROM subparameter, and on or earlier than the date specified in the UNTIL subparameter. There are two possibilities:

  1. The date specified in the FROM subparameter is earlier than that specified in the UNTIL subparameter.

     Copy

     DEFINITION ACTIVE FROM   091002 UNTIL   011102

     The job can only be ordered on or between October 9, 2002 and November 1, 2002.

  2. The date specified in the FROM subparameter is later than that specified in the UNTIL subparameter.

     Copy

     DEFINITION ACTIVE FROM   090502 UNTIL   010402

     The job can only be ordered on or after May 9, 2002, or before or on April 1, 2002, but not between those dates.

• If you specify the FROM subparameter, but not the UNTIL subparameter, the job cannot be ordered before the date specified, but can be ordered on or at any time later than that date.

  Copy

  DEFINITION ACTIVE FROM   091002 UNTIL

  The job can only be ordered on or after October 9, 2002.

• If you do not specify the FROM subparameter, but specify the UNTIL subparameter, the job can be ordered on or at any time earlier than the date specified, but not later than that date.

  Copy

  DEFINITION ACTIVE FROM             UNTIL   011102

  The job can only be ordered on or before November 1, 2002.

• If you do not specify either the FROM or UNTIL subparameters, there is no restriction on the date when the job can be ordered.

  Copy

  DEFINITION ACTIVE FROM             UNTIL

  The job can be ordered on any date.

DESC: General Job Parameter

Description of the job to be displayed in the Job List screen.

Figure 182 DESC Parameter Format

(Optional) This parameter may consist of text of 1 through 4000 characters. DESC lines hold 70 characters each and are added as needed.

General Information for DESC

The DESC parameter is informational. It does not affect job processing. It serves as internal documentation, to let the user know the purpose of (or some other key information about) the job.

The description specified in the DESC parameter appears to the right of the job name in the Job List screen.

Text for the DESC parameter can be specified in any language.

For information on how to specify more detailed job documentation, see Job Documentation.

Example for DESC

JOB: OPERCOMP LIB CTM.PROD.SCHEDULE                       TABLE: OPER
COMMAND ===>                                          SCROLL===> CRSR
+-------------------------------------------------------------------+
  MEMNAME OPERCOMP    MEMLIB   CTM.PROD.JCL                          
  OWNER   SYS1        TASKTYPE JOB    PREVENT-NCT2   DFLT  N         
  APPL    OPER                        GROUP MAINTENANCE              
  DESC    JOB RUN ON THE 1ST OF THE MONTH                     
  OVERLIB                                                   STAT CAL
  SCHENV                         SYSTEM ID                NJE NODE   
  SET VAR                                                           
  CTB STEP AT         NAME            TYPE                          
  DOCMEM  OPERCOMP    DOCLIB   CTM.PROD.DOC                         
  ===================================================================
SCHEDULE RBC                                                         
RELATIONSHIP (AND/OR) O                                              
DAYS                                                        DCAL     
                                                               AND/OR 
WDAYS                                                       WCAL     
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES                                                                
CONFCAL          SHIFT       RETRO N MAXWAIT 04   D-CAT              
MINIMUM PDS  
DEFINITION ACTIVE FROM UNTIL
  ===================================================================
  IN                                                                 
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                          11.17.00

DO Statement: Post–processing Parameter

Actions taken when the ON step and codes event criteria are satisfied.

Figure 184 DO Parameter Format

(Optional) Specify DO statements as follows:

• Type the action keyword (such as COND) in the DO field and press Enter.

• In many cases, subparameter fields are displayed. Fill in the subparameters and press Enter again.

• Multiple DO statements can be specified. After entering a DO statement, another DO line is automatically displayed.

DO actions are described in Table 176. Each is discussed in detail in this chapter.

Table 176 DO Actions

General Information for DO Statement

DO statements are generally paired with the preceding ON PGMST, ON PROCST, or ON CODES statements (all of which are described in this chapter). Their implied relationship is:

Table 177 Relationship of DO Statements with Other Statements

All specified DO statements have an AND relationship.

To add an empty DO statement between two existing DO statements, type the > character over the first letter in the DO field of the earlier DO statement, and press Enter.

Example for DO Statement

DO >OND

DO COND: Post–processing Parameter

Specifies prerequisite conditions to be added or deleted if the accompanying ON step and code criteria are satisfied.

Figure 185 DO COND Parameter Format

(Optional) Type COND in the DO field and press Enter.

A maximum of two prerequisite conditions can be specified in each standard DO COND line. One prerequisite condition can be specified in each long DO COND line. When you specify the second prerequisite condition in a standard DO COND line, or one prerequisite condition in a long DO COND line, and press Enter, a new DO COND line is opened for specifying additional prerequisite conditions. For more information, see Specifying Long DO COND Condition Names.

Each DO COND statement consists of the mandatory subparameters described in Table 178.

Table 178 DO COND Mandatory Subparameter Formats

General Information for DO COND

When a DO COND statement is activated, the specified prerequisite conditions are added to or deleted from the IOA Conditions file according to the value set for opt.

Prerequisite conditions are usually used to establish job dependencies or ensure manual intervention when required.

• To establish a job dependency, define a prerequisite condition in an OUT or DO COND statement in the job that must run first, and in an IN statement in the job that must run afterwards.

  The job containing a prerequisite condition in its IN statement is not submitted unless that prerequisite condition has been added manually or by the job containing an OUT or DO COND statement.

  An OUT statement is used to add the prerequisite condition if the job ends OK.

  Use a DO COND statement to add the prerequisite condition if the step and code event criteria specified in the accompanying ON statement are satisfied.

• If the IN prerequisite condition can only be satisfied by manual intervention (for example, TAPE1-ARRIVED is set by the operator after an external tape has arrived insight), performance of the required manual intervention before job submission is ensured.

OUT and DO COND statements can also be used to delete prerequisite conditions. The OUT statement of the job can be used to delete the prerequisite condition after the job ends OK. A DO COND statement can be used to delete prerequisite conditions if the accompanying ON step and code criteria are satisfied.

These statements are generally used to delete prerequisite conditions either to prevent a particular job from running or when the condition is no longer needed by any other jobs in the Active Jobs file.

DO COND functions are performed after the functions of the OUT parameter.

• If a prerequisite condition is added by the OUT parameter and deleted by the DO COND parameter, the combined effect is the deletion of the prerequisite condition.

• If a prerequisite condition is deleted by the OUT parameter and added by the DO COND parameter, the combined effect is the addition of that prerequisite condition.

IMS-ACTIVE
JOB_PAYCALC_ENDED_OK
TAPE1_LOADED

All prerequisite conditions are associated with a date reference that is used to distinguish between different runs of the same job with different scheduling dates. If, for example, a condition is being deleted, only the condition matching the specified date is deleted. The same condition associated with a different date is not deleted. When adding or deleting prerequisite conditions, the date associated with the prerequisite condition can be a specific 4-character date or one of the symbolic dates described in the explanation of parameter "dateref" in DO COND: Post–processing Parameter.

Prerequisite conditions created by a DO COND statement can trigger the execution of other jobs or processes.

Prerequisite conditions deleted by a DO COND statement can prevent the execution of jobs and processes whose IN statements require those prerequisite conditions.

If two or more DO COND statements are contradictory, statements performed earlier are overridden by statements that are performed later.

For more information regarding prerequisite conditions, see IN: Runtime Scheduling Parameter, ON Statements: Post–processing Parameter, and OUT: Post–processing Parameter, and see Prerequisite Conditions.

Specifying Long DO COND Condition Names

Regular prerequisite conditions are not more than 20 characters in length. If you want to specify a longer condition name, up to 39 characters in length, enter the string LONG in the date reference field of an empty DO COND condition line. An (L) appears at the beginning of the line. If the field already contains data, entering the string LONG will open a new long DO COND parameter, with (L) appearing at the beginning of the line. You can now insert a long condition name, as illustrated in Figure 186.

Specify SHRT in the date reference field to revert back to condition names of standard length.

Figure 186 Long DO COND Condition

JOB: IEFBR14  LIB CTMP.V610.SCHEDULE                      TABLE: PHILL1
COMMAND ===>                                            SCROLL===> CRSR
+---------------------------------------------------------------------+
  IN      CTM-DAILYPRD-ENDEDXX ODAT      CTM-DAILYSYS-ENDEDXX ODAT    
  CONTROL                                                              
  RESOURCE                                                             
  PIPE                                                                 
  FROM TIME         +     DAYS    UNTIL TIME      +     DAYS  
  DUE OUT TIME      +     DAYS    PRIORITY 00  SAC    CONFIRM 
  TIME ZONE:                                                           
  =====================================================================
  OUT                                                                  
  AUTO-ARCHIVE Y           SYSDB    Y     MAXDAYS     MAXRUNS          
  RETENTION:  # OF DAYS TO KEEP        # OF GENERATIONS TO KEEP        
  SYSOUT OP   (C,D,F,N,R)                                          FROM
  MAXRERUN      RERUNMEM                           INTERVAL      FROM  
  STEP RANGE         FR (PGM.PROC)            .          TO       .    
  ON PGMST +EVERY   PROCST STEP1      CODES SOC4                    A/O
    DO COND      (L) THIS-IS-A-LONG-DO-C0ND-CONDITION-NAME ODAT  
  ON PGMST          PROCST            CODES                         A/O
    DO                                                                 
  ON SYSOUT                                       FROM 01 TO 132    A/O
    DO                                                                 
  ON VAR                                                               
    DO                                                                 
  SHOUT WHEN NOTOK     TIME       +     DAYS     TO OPER2        URGN R 
    MS   LOADING OF MANUAL CONDITIONS SCREEN FAILED. CALL OP MANAGER.  
  SHOUT WHEN           TIME       +     DAYS     TO              URGN   
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                            16.30.17

Differences between OUT and DO COND

OUT and DO COND statements have the following differences:

• An OUT statement is applied only if the job ends OK. DO COND statements are associated with accompanying ON statements and are applied only if the accompanying ON step and code criteria are satisfied.

• An OUT statement appears in each job scheduling definition. No DO COND statement appears unless specified. To specify a DO COND statement, type COND in an empty DO field and press Enter.

• DO COND statements are processed after OUT statements and can therefore override OUT statements.

• MVS restart can only be requested from an OUT statement, not a DO COND statement.

Example for DO COND

JOB: IMSPROD  LIB CTM.PROD.SCHEDULE                      TABLE: IMSPROD
COMMAND ===>                                            SCROLL===> CRSR
+---------------------------------------------------------------------+
  =====================================================================
  OUT      IMS-ACTIVE           **** -                                 
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS         
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP          
  SYSOUT OP   (C,D,F,N,R)                                        FROM  
  MAXRERUN      RERUNMEM                           INTERVAL     FROM   
  STEP RANGE         FR (PGM.PROC)          .          TO        .     
  ON PGMST STEP01   PROCST          CODES U0421                   A/O  
    DO COND          CHANGE ACCUMULATION  ODAT +                  
    DO                                                                 
  ON PGMST STEP01   PROCST          CODES U0428                   A/O  
    DO COND          LOGCLOSE-NEEDED      ODAT +                 
    DO                                                                 
  ON PGMST STEP01   PROCST          CODES U0426                    A/O 
    DO SHOUT     TO  U-DBA              URGENCY V                      
     = *** IMSPROD ABENDED WITH U0426 ****                             
    DO                                                                 
  ON PGMST          PROCST          CODES                          A/O  
    DO                                                                 
  ON SYSOUT                                       FROM 01 TO 132    A/O
    DO                                                                 
  ON VAR                                                               
    DO                                                                 
  SHOUT WHEN           TIME       +     DAYS     TO             URGN   
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                            11.17.00

DO CTBRULE: Post–processing Parameter

Invokes a Control-M/Analyzer rule to be executed during the processing of a specific program step. Available only at sites utilizing Control-M/Analyzer.

Figure 188 DO CTBRULE Parameter Format

(Optional) Type CTBRULE in the DO field and press Enter. The DO CTBRULE subparameters are described in Table 179.

Table 179 DO CTBRULE Subparameters

General Information for DO CTBRULE

When DO CTBRULE is specified, balancing is performed by the Control-M/Analyzer Runtime environment according to the specified rule definition and using the specified arguments. The Control-M/Analyzer Runtime environment is invoked once for each DO CTBRULE statement in the job scheduling definition.

When Control-M calls a Control-M/Analyzer rule, the Control-M/Analyzer System variable SYSOPT contains the value CTMWORK. This variable can then be tested within the Control-M/Analyzer rule definition to determine if Control-M invoked the Control-M/Analyzer Runtime environment.

When the Control-M/Analyzer Runtime environment is invoked by Control-M, that is, the Control-M/Analyzer System variable SYSOPT is set to CTMWORK, Control-M/Analyzer can analyze and balance SYSDATA. For more information about invoking Control-M/Analyzer rules from Control-M job scheduling definitions, see the discussion of the interface to Control-M in the Control-M/Analyzer FOR z/OS User Guide.

Example for DO CTBRULE

JOB: GOVTREPT LIB CTM.PROD.SCHEDULE                       TABLE: BACKUP
COMMAND ===>                                            SCROLL===> CRSR
+---------------------------------------------------------------------+
  TIME: FROM       UNTIL       PRIORITY     DUE OUT       SAC  CONFIRM 
  TIME ZONE:                                                           
  =====================================================================
  OUT      FINANCE-GOVTREPT-OK  ODAT +                                 
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS         
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP          
  SYSOUT OP   (C,D,F,N,R)                                        FROM  
  MAXRERUN     RERUNMEM                          INTERVAL       FROM  
  STEP RANGE         FR (PGM.PROC)          .          TO          .   
  ON PGMST ANYSTEP  PROCST          CODES OK                      A/O  
    DO CTBRULE   = GOVTBAL  ARG DOREPORT,10,%%ODATE                
    DO                                                                 
  ON PGMST          PROCST          CODES                         A/O  
    DO                                                                 
  ON SYSOUT                                     FROM 01 TO 132    A/O
    DO                                                                 
  ON VAR                                                               
    DO                                                                 
  SHOUT WHEN NOTOK     TIME       +     DAYS     TO TS0-M44      URGN R 
    MS JOB GOVTREPT ENDED "NOT OK"                                    
  SHOUT WHEN           TIME       +     DAYS     TO             URGN   
    MS                                                                 
 ======= >>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<< ======
                                                                      
COMMANDS: EDIT, DOC, PLAN, JOBSTAT                             11.17.00

DO FORCEJOB: Post–processing Parameter

Force one or more jobs under Control-M.

Figure 190 DO FORCEJOB Parameter Format

(Optional) Type FORCEJOB in the DO field and press Enter. The DO FORCEJOB subparameters are described in Table 180.

Table 180 DO FORCEJOB Subparameter Formats

General Information for DO FORCEJOB

The DO FORCEJOB statement schedules jobs under Control-M even if the jobs are not normally scheduled on the specified date (according to the Basic Scheduling parameters of the job). It is similar to the FORCE option in the Control-M Rule List screen or Table List screen.

If the DO FORCEJOB statement specifies a job name belonging to multiple jobs in the table, the first job in the table with that job name is forced.

Without the DO FORCEJOB statement, emergency jobs and jobs that run in special circumstances would require daily scheduling or manual forcing (from the Online facility). By defining appropriate ON criteria and DO FORCEJOB statements, emergency or other special jobs can be automatically forced when required without being previously scheduled.

The DO FORCEJOB statement causes the Control-M monitor to dynamically allocate the job scheduling library specified in the LIBRARY parameter using the DD name ONSPLT.

When forcing all jobs in a table, the UFLOW subparameter enables you to determine whether the jobs are run as a unique flow.

DO FORCEJOB request during RESTART

The FORCONCE parameter in the CTMPARM member of the IOA PARM library may be set to control the behavior of DO FORCEJOB requests during a Restart of a job.

If DO FORCEJOB statements are not to be executed during the RESTART of a job if they were already executed during the original run of the job or during a previous RESTART of the job, then the FORCONCE parameter should be set to Y.

If DO FORCEJOB statements are always to be executed during the RESTART of a job (when the ON PGMST condition is satisfied), then the FORCONCE parameter should be set to N.

Failure of a DO FORCEJOB request

When a DO FORCEJOB request fails because the table is in use, Control-M may try again to execute the job, depending on the values set for the FORCE#RT and FORCE#WI installation parameters. For more information on the FORCE#RT and FORCE#WI installation parameters, see the INCONTROL for z/OS Installation Guide: Customizing.

When a DO FORCEJOB request fails because the table has been migrated, the action of Control-M depends on the value of the SCRECALL parameter in the CTMPARM member.

• If the value of SCRECALL is Y, the table is recalled, and Control-M tries to reorder the job in the same way as if the table is in use.

• If the value of SCRECALL is N, the table is not recalled, and the job is not scheduled. This is the default setting of SCRECALL.

For more information on the SCRECALL parameter, see the customization chapter of the INCONTROL for z/OS Installation Guide: Customizing.

Example for DO FORCEJOB

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE                     TABLE: PRODKPL
COMMAND ===>                                           SCROLL===> CRSR
+--------------------------------------------------------------------+
  ====================================================================
  OUT      PRDKPL01-ENDED-OK    ODAT +                                
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRU          
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEE          
  SYSOUT OP   (C,D,F,N,R)                                       FROM  
  MAXRERUN     RERUNMEM                       INTERVAL       FROM     
  STEP RANGE         FR (PGM.PROC)          .   TO          .         
  ON PGMST ANYSTEP  PROCST          CODES S***   U****           A/O  
    DO FORCEJOB  TABLE  EMRJOBS    JOB PRDKPLSP  UFLOW N    DATE ODAT 
                 LIBRARY CTM.PROD.SCHEDULE                        
    DO                                                                
  ON PGMST          PROCST          CODES                        A/O  
    DO                                                                
  ON SYSOUT                                    FROM 01 TO 132    A/O
    DO                                                                 
  ON VAR                                                               
    DO                                                                 
  SHOUT WHEN NOTOK     TIME       +     DAYS     TO TS0-T4    URGN R  
    MS PRDKPL01 ENDED NOT OK, PLEASE CHECK IT                         
  SHOUT WHEN LATESUB    TIME 0200  +   DAYS  TO U-SHIFT-MANAGER  URGN R 
    MS PRDKPL01 WAS NOT SUBMITTED YET, PLEASE CHECK WHY               
  SHOUT WHEN           TIME       +     DAYS     TO            URGN   
    MS                                                                
 ======= >>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<< ======
COMMANDS: EDIT, DOC, PLAN, JOBSTAT                            11.17.00

Confirmation Panel for DO FORCEJOB

If the DFJCONF profile variable is set to Y, and the JOB parameter in the DO FORCEJOB request is blank, a confirmation panel is displayed when exiting the Job Scheduling Definition screen. The confirmation panel is displayed only once for each DO FORCEJOB statement.

Figure 192 DO FORCEJOB Confirmation Panel

+----------------------------------------------------------+
|                                                          |
|  THIS JOB CONTAINS ONE OR MORE DO FORCEJOB STATEMENTS.   |
|  WHEN THE JOB IS ORDERED:                                |
|  ARE YOU SURE YOU WANT TO FORCE THE WHOLE TABLE IN THE   |
|  FORCEJOB STATEMENT(S)?    (Y/N)                         |
|                                                          |
+----------------------------------------------------------+

Enter Y to save the table and return to the Job List screen, or N to return to the table without saving it.

§Restart§DO IFRERUN: Post–processing Parameter

Job steps to be executed during restart of a job. Available only at sites utilizing Control-M/Restart.

Figure 193 §Restart§ DO IFRERUN Parameter Format

(Optional) Type IFRERUN in the DO field and press Enter. The DO IFRERUN subparameters are described in Table 181.

Table 181 §Restart§ DO IFRERUN Subparameter Formats

General Information for DO IFRERUN

When a DO IFRERUN statement is specified, the rerun is performed by the Restart facility of Control-M/Restart using the specified restart subparameters.

• When DO IFRERUN is specified with a CONFIRM value of N (No):

  • If a DO RERUN statement follows, the job is automatically submitted for rerun.

  • If a DO RERUN statement does not follow, the job is not automatically rerun. Instead, the job remains displayed with its error status in the Active Environment screen.

    In this case, to submit the job for rerun or restart, specify option R (Rerun) in the Active Environment screen. The Rerun (with Restart) Confirmation Window is displayed. Request the restart or rerun from the window.

• When DO IFRERUN is specified with a CONFIRM value of Y (Yes), the job appears in the Active Environment screen with a WAIT CONFIRMATION (WITH RESTART) status and is not restarted unless confirmed. Specify option C (Confirm) to open the Confirm window to restart the job.

§Restart§ For more information about job restart, see Active Environment Screen.

§Restart§ When a job is submitted for restart, if $FIRST is specified in the FROM subparameter, a $FIRST step specification is passed "as is" to the CONTROLR step. If $ABEND or $EXERR is specified, the specified $ABEND or $EXERR value is first resolved to the appropriate step by the Control-M monitor and then passed to the CONTROLR step. If $FIRST.$ABEND is specified, the Control-M monitor determines which procedure abended and then passes the $FIRST step specification for that procedure to the CONTROLR step. For information regarding the CONTROLR step, refer to the Control-M/Restart User Guide.

§Restart§ The Control-M parameter MAXRERUN determines the maximum number of times the restart or rerun can be performed. For more information, see MAXRERUN: Post–processing Parameter.

§Restart§ Example for DO IFRERUN

JOB: PRDKL02 LIB CTM.PROD.SCHEDULE                      TABLE: PRODKPL
COMMAND ===>                                           SCROLL===> CRSR
+--------------------------------------------------------------------+
  TIME: FROM       UNTIL     PRIORITY     DUE OUT   SAC     CONFIRM   
  ====================================================================
  OUT                                                                 
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUN         
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP         
  SYSOUT OP   (C,D,F,N,R)                                       FROM  
  MAXRERUN      RERUNMEM                    INTERVAL         FROM     
  STEP RANGE         FR (PGM.PROC)       .      TO          .         
  ON PGMST ANYSTEP  PROCST UPDA     CODES S**** U**** C2000      A/O  
    DO IFRERUN   FROM $ABEND              TO                 CONFIRM N
    DO RERUN                                                          
    DO                                                                
  ON PGMST          PROCST          CODES                        A/O  
    DO                                                                
  ON SYSOUT                                    FROM 01 TO 132    A/O
    DO                                                                 
  ON VAR                                                               
    DO                                                                 
  SHOUT WHEN           TIME       +     DAYS     TO            URGN   
    MS                                                                
======= >>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<< =====
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                           15.26.42

DO MAIL: Post–processing Parameter

Send an e-mail message to the specified recipients.

Figure 195 DO MAIL Parameter Format

  ON PGMST               PROCST          CODES                    A/O
     DO MAIL                          ATTACH SYSOUT                  
   TO
   CC
   SUBJ
   TEXT

(Optional) Type MAIL in the DO field and press Enter. The DO MAIL subparameters are described in Table 182.

Table 182 DO MAIL Subparameter Formats

General Information for DO MAIL

The specified e-mail is sent to the specified destinations when the accompanying ON statement criteria are satisfied. Although an e-mail can be sent using a DO SHOUT statement, the DO MAIL statement provides the following advantages:

• Using DO MAIL, you can specify any number of TO and CC recipients. With DO SHOUT, you must specify the mail destination prefix, and you must define the address in the MAILDEST table.

• Using DO MAIL, the e-mail text can exceed 70 characters. System variables and user-defined AutoEdit variables (Global IOA variables and variables defined in the SET VAR job scheduling definition parameter only) are supported in the subject line and message text. These variables are resolved when the DO MAIL statement is processed.

If installation parameter ATTSYSOT=Y, the job's SYSOUT will be attached to the email message. Setting ATTSYSOT=Y ensures that the SYSOUT is attached to any job where DO Mail is specified.

However, if you only need to attach SYSOUTs to specific jobs, then set ATTSYSOT=N, and set the ATTACH SYSOUT subparameter to Y only for those specific jobs.

The SYSOUT attached to the email message is the first three SYSOUT datasets of the job. The attachment file name has the following format:

<jobname>-D<ldate>-O<orderid>-R<run-number>.txt

The file attachment size limit, if any, is determined by the Control-M ATTSOTSZ customization parameter. See the INCONTROL for z/OS Installation Guide for details.

Subparameters TO and CC

Each of these parameters can contain more than one mail name address. When a value is specified in the TO or CC field, a new empty line is displayed so that an additional value can be specified (up to a maximum of 255 lines).

Multiple addresses, separated by a semicolon (;), can be specified on a line.

If an address exceeds the length of a full line, it can be continued on the following line.

Example for DO MAIL

JOB: SACALC01 LIB CTM.PROD.SCHEDULE                       TABLE: SALES
COMMAND ===>                                            SCROLL===> CRSR
+---------------------------------------------------------------------+
  =====================================================================
  OUT                                                                  
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS         
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP          
  SYSOUT OP   (C,D,F,N,R)                                        FROM  
  MAXRERUN     RERUNMEM                          INTERVAL      FROM    
  STEP RANGE         FR (PGM.PROC)          .        TO       .        
  ON PGMST ANYSTEP  PROCST          CODES JNRUN                   A/O  
    DO MAIL                          ATTACH SYSOUT Y              
  TO   MAIL_ADDRESS_#1                                            
       MAIL_ADDRESS_#2                                            
  CC   MAIL_ADDRESS_#3;MAIL_ADDRESS_#4                            
  SUBJ WARNING MESSAGE                                            
  TEXT JCL ERROR IN SALES JOB! PLEASE CORRECT ERRORS AND RERUN THE JOB
    DO                                                                 
  ON PGMST          PROCST          CODES                         A/O  
    DO                                                                 
  ON SYSOUT                                     FROM 01 TO 132    A/O
    DO                                                                 
  ON VAR                                                               
    DO                                                                 
  SHOUT WHEN           TIME       +     DAYS     TO             URGN   
    MS                                                                 
======= >>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<< =====
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                            11.17.00

DO NOTOK: Post–processing Parameter

Set the status of the job step to NOTOK if the accompanying ON step and code criteria are satisfied. If specified in a SMART Table Entity, the termination status of the SMART Table is set to NOTOK.

Figure 197 DO NOTOK Parameter Format

(Optional) Type NOTOK in the DO field and press Enter. DO NOTOK has no subparameters.

General Information for DO NOTOK

A DO NOTOK statement can change the status of a job step from OK to NOTOK. This results in the job having a final termination status of ENDED NOTOK.

When specified in a SMART Table Entity, a DO NOTOK statement changes the termination status of the SMART Table (not the status of jobs or job steps).

The following paragraphs describe the relationship of job step status and the final termination status of the job.

• Control-M determines the status of each individual step in a job before determining the final status of the job.

• After examining the results of a job step, Control-M automatically assigns a status of OK or NOTOK to the step:

  • By default, any job step ending with a condition code of C0000 through C0004 is assigned a status of OK, but the INCONTROL administrator can change this.

  • If any other condition code, system or user abend code, or user event is generated, the step is automatically assigned a status of NOTOK.

• In general, if any of the steps in a job ends with a status of NOTOK, the job is assigned a final status of ENDED NOTOK. For a job to be assigned a final status of ENDED OK, each step in the job must be assigned a status of OK.

This logic suits most situations. Do not change it. However, there may be a situation in which Control-M assigned a step a status of OK, but the status ought to be changed to NOTOK. Such a situation is described in the following example. The job ended with a condition code of C0004, but in this particular situation, it is better that the step have a status of NOTOK and the entire job be assigned a status of ENDED NOTOK.

DO NOTOK cannot be specified for the same ON step and code event as DO OK.

When a DO NOTOK statement is performed for a step, the final status of the job is ENDED NOTOK, even if was previously set to ENDED OK.

Example for DO NOTOK

JOB: PRDKPL02 LIB CTM.PROD.SCHEDULE                      TABLE: PRODKPL
COMMAND ===>                                           SCROLL===> CRSR
+---------------------------------------------------------------------+
  OUT                                                                  
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS         
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP          
  SYSOUT OP   (C,D,F,N,R)                                         FROM 
  MAXRERUN     RERUNMEM                          INTERVAL      FROM    
  STEP RANGE         FR (PGM.PROC)        .         TO        .        
  ON PGMST STEP06   PROCST UPDA     CODES C0004                   A/O  
    DO NOTOK                                                      
    DO                                                                 
  ON PGMST          PROCST          CODES                          A/O 
    DO                                                                 
  ON SYSOUT                                       FROM 01 TO 132    A/O
    DO                                                                 
  ON VAR                                                               
    DO                                                                 
  SHOUT WHEN           TIME       +     DAYS     TO             URGN   
    MS                                                                 
 ======= >>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<< ===
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                            15.16.03

DO OK: Post–processing Parameter

Set the status of the job step to OK if the accompanying ON step and code criteria are satisfied. If specified in a SMART Table Entity, the termination status of the SMART Table is set to OK.

Figure 199 DO OK Parameter Format

(Optional) Type OK in the DO field and press Enter. DO OK has no subparameters.

General Information for DO OK

A DO OK statement can change the status of a job step from NOTOK to OK. If all steps of a job have a status of OK the job is assigned a final termination status of ENDED OK.

When specified in a SMART Table Entity, a DO OK statement changes the termination status of the SMART Table (not the status of jobs or job steps).

The relationship between job step status and the final termination status of the job is as follows:

Control-M determines the status of each individual step in a job before determining the final status of the job.

After examining the results of a job step, Control-M automatically assigns a status of OK or NOTOK to the step:

• By default, any job step ending with a condition code of C0000 through C0004 is assigned a status of OK, but the INCONTROL administrator can change this.

• If any other condition code, system or user abend code, or user event is generated, the step is automatically assigned a status of NOTOK.

In general, if any of the steps in a job ends with a status of NOTOK, the job is assigned a final status of ENDED NOTOK. For a job to be assigned a final status of ENDED OK, each step in the job must be assigned a status of OK.

This logic suits most situations. Do not change it. However, there may be a situation in which Control-M assigned a step a status of NOTOK, but the status ought to be changed to OK. Several such exceptional situations are described below:

• The NOTOK status is inappropriate for the job step. For example, a condition code greater than C0004 was returned for a step that had an acceptable result.

• The NOTOK status is appropriate for the job step, but the job step is not critical, and ought not to affect the final job status.

• User events created using Exit CTMX003 always result in a NOTOK status unless DO OK is specified.

DO OK cannot be specified for the same ON step and code event as DO NOTOK and DO RERUN.

A DO OK statement specified in the job scheduling definitions is ignored if one of the following occurs:

• any of the following status codes apply to any step:

  • EXERR

  • JNSUB

  • *REC0

  • *UKNW

• it was specified as part of an ON PGMSTEP ANYSTEP ..... CODE NOTOK condition, because if that condition is satisfied, the status of the job has already been set to NOTOK

• it is specified in an ON PGMST +EVERY statement

For more information, see CODES Values.

Since the DO OK action is inherently associated with a job step and not the job as a whole, its interaction with the reserved step name ANYSTEP is as follows:

The return code of each step of the job is examined to determine whether it satisfies the codes specified in the CODES parameter. If the CODES are satisfied, that step is 'explained' and that particular step is given a status of OK. Any job step whose return code does not satisfy the CODES is 'unexplained' and will cause a SEL216W message to be issued and the corresponding job step to be marked as NOTOK. The job's final status is then determined as described above.

Example for DO OK

JOB: PRDKPL02 LIB CTM.PROD.SCHEDULE                     TABLE: PRODKPL
COMMAND ===>                                           SCROLL===> CRSR
+--------------------------------------------------------------------+
  OUT                                                                 
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS        
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP         
  SYSOUT OP   (C,D,F,N,R)                                        FROM 
  MAXRERUN     RERUNMEM                             INTERVAL   FROM    
  STEP RANGE         FR (PGM.PROC)          .        TO        .      
  ON PGMST STEP08   PROCST UPDA     CODES <C0008                  A/O 
    DO OK                                                         
    DO                                                                
  ON PGMST          PROCST          CODES                         A/O 
    DO                                                                
  ON SYSOUT                                     FROM 01 TO 132    A/O
    DO                                                                
  ON VAR                                                              
    DO                                                                
  SHOUT WHEN           TIME       +     DAYS     TO            URGN   
    MS                                                                
======= >>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<< ======
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                          15.16.03

DO REMEDY: Post–processing Parameter

Open a problem ticket within the Remedy Helpdesk System, for example, when a specific job fails.

Figure 201 DO REMEDY Parameter Format

(Optional) Type REMEDY in the DO field and press Enter. The DO REMEDY subparameters are described in Table 183.

Table 183 DO REMEDY Subparameter Formats

General Information for DO REMEDY

An e-mail message is sent to the Remedy Helpdesk when the accompanying ON statement criteria are satisfied. To close the ticket, you must access the Remedy online service. You can use AutoEdit variables in the SUMM and DESC fields, in any combination of text and valid AutoEdit variables.

Example for DO REMEDY

JOB: SACALC01 LIB CTMP.V700.SCHEDULE                     TABLE: SALES
COMMAND ===>                                           SCROLL===> CRSR
+---------------------------------------------------------------------+
| =================================================================== |
| OUT                                                                 |
| AUTO-ARCHIVE Y          SYSDB    Y     MAXDAYS     MAXRUNS          |
| RETENTION:  # OF DAYS TO KEEP     # OF GENERATIONS TO KEEP          |
| SYSOUT OP   (C,D,F,N,R)                                      FROM   |
| MAXRERUN      RERUNMEM                        INTERVAL    FROM      |
| STEP RANGE         FR (PGM.PROC)          .        TO       .       |
| ON PGMST ANYSTEP  PROCST          CODES JNRUN                 A/O   |
|   DO REMEDY                           URGENCY U                     |
| SUMM JCL ERROR IN SALES JOB                                         |
|                                                                     |
| DESC A JCL ERROR OCCURED IN THE SALES JOB.  PLEASE CORRECT AND      |
| RERUN THE JOB.                                                      |
|                                                                     |
|   DO                                                                |
| ON PGMST          PROCST          CODES                       A/O   |
|   DO                                                                |
| ON SYSOUT                                  FROM 001 TO 132    A/O   |
|   DO                                                                |
| ON VAR                                                              |
|   DO                                                                |
| SHOUT WHEN          TIME       +     DAYS    TO            URGN     |
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                            17.44.21

DO REMFORCE: Post–processing Parameter

Force one or more jobs under a remote Control-M with the capability of passing parameters to the target job(s).

Figure 203 DO REMFORCE Parameter Format

     DO REMFORCE    CONTROL-M   MPM900               UFLOW N DATE 251214
 TABLE table_name                                                      
 JOB  jobname 
 LIBRARY             
 VAR  %%Var1=Value1
 VAR  %%Var2=Value2

(Optional) Type REMFORCE in the DO field and press Enter. The DO REMFORCE subparameters are described in Table 184.

Table 184 DO REMFORCE Subparameter Formats

General Information for DO REMFORCE

The DO REMFORCE statement schedules jobs under a remote Control-M even if the jobs are not normally scheduled on the specified date (according to the Basic Scheduling parameters of the job).

If the DO REMFORCE statement specifies a job name belonging to multiple jobs in the table, the first job in the table with that job name is forced.

For a list of valid Control-M server names for use in the CONTROL-M sub-parameter, open the Control-M Configuration Manager (CCM). Valid Control-M server names are displayed in the "Name" column for entries of Type ‘Control-M Server’.

To determine whether a particular datacenter is a mainframe (MF) or a distributed (DS) datacenter, select the entry and in the Properties pane, under the "More properties" section, read what is displayed by the "Operation system" heading. A mainframe datacenter is indicated by "z/OS nn.mm". (Double clicking on the Control-M Server entry will also display the server definitions.)

In order to successfully execute a DO REMFORCE statement, the job’s OWNER must be defined in Control-M/EM.

When forcing all jobs in a table, the UFLOW subparameter enables you to determine whether the jobs are run as a unique flow.

Example for DO REMFORCE

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE                      TABLE: PRODKPL
COMMAND ===>                                            SCROLL===> CRSR
+---------------------------------------------------------------------+
  =====================================================================
  OUT      PRDKPL01-ENDED-OK    ODAT +                                 
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS         
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP          
  SYSOUT OP   (C,D,F,N,R)                                        FROM  
  MAXRERUN     RERUNMEM                              INTERVAL   FROM   
  STEP RANGE         FR (PGM.PROC)          .          TO          .   
  ON PGMST ANYSTEP  PROCST          CODES S***   U****            A/O  
    DO REMFORCE    CONTROL-M   MVS900              UFLOW N DATE 251214 
  TABLE   EMRJOBS       
  JOB   PRDKPLSP     
  LIBRARY CTM.PROD.SCHEDULE
  VAR  %%Var1=Value1
  VAR  %%Var2=Value2
      DO                                                              
  ON PGMST          PROCST          CODES                        A/O  
    DO                                                                
  ON SYSOUT                                   FROM 001 TO 132    A/O  
    DO                                                                
  ON VAR                                                              
    DO                                                                
  SHOUT WHEN NOTOK     TIME       +     DAYS     TO TS0-T43    URGN R  
    MS PRDKPL01 ENDED NOT OK, PLEASE CHECK IT                         
  SHOUT WHEN LATESUB    TIME 0200  +   DAYS  TO U-SHIFT-MANAGER  URGN R 
    MS PRDKPL01 WAS NOT SUBMITTED YET, PLEASE CHECK WHY                
  SHOUT WHEN           TIME       +     DAYS     TO            URGN   
    MS                                                                
 ======= >>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<< ======
COMMANDS: EDIT, DOC, PLAN, JOBSTAT                             11.17.00

DO RERUN: Post–processing Parameter

Reschedules the job (for rerun) if the accompanying ON step and code criteria are satisfied.

Figure 205 DO RERUN Parameter Format

(Optional) Type RERUN in the DO field and press Enter. DO RERUN has no subparameters.

General Information for DO RERUN

The RERUN statement is intended for situations in which a job must be rescheduled following an unsuccessful job run.

Rerun jobs remain in the Active Jobs file with a status of WAIT SCHEDULE, where they wait to be submitted like any other job. However, other parameters, such as CONFIRM and DO IFRERUN, can affect the status of the rerun job order and the submission and processing of the job:

• A Y value specified in the CONFIRM parameter indicates that manual confirmation is required before submitting the rerun job order. In this case, the rerun job order is placed in the Active Jobs file with a status of WAIT CONFIRMATION (FOR SCHEDULE). The job can be confirmed by option C (Confirm) in the Active Environment screen.

• A DO IFRERUN statement before the DO RERUN statement indicates that a restart is desired instead of a full rerun. The job order is placed in the Active Jobs file with a status of WAIT SCHEDULE – WITH RESTART, where the job waits to be submitted from the indicated restart step. Confirmation can also be required for restart jobs. This, too, is performed from the Active Environment screen. For more information, see §Restart§DO IFRERUN: Post–processing Parameter.

For information about confirmation, see Confirm Rerun Window and §Restart§Rerun and/or Restart Window (Under Control-M/Restart).

Job rerun is also affected by the MAXRERUN, RERUNMEM and INTERVAL parameters.

• MAXRERUN specifies the maximum number of times the job must be scheduled for rerun.

• RERUNMEM specifies the JCL member to be used for the rerun (if different from the normal JCL member of the job).

• INTERVAL specifies the number of minutes to wait between reruns.

These parameters are described in this chapter.

DO RERUN cannot be specified for a cyclic job or a cyclic started task.

DO RERUN cannot be specified for the same ON step and code event as DO OK.

Do not specify DO RERUN for steps that have a specified ON statement code value of OK.

Do not specify DO RERUN for steps that have a specified ON statement code value of NOTOK because many of the causes of a NOTOK status, such as JCL not found, preclude the possibility of a successful job rerun. Instead, specify an ON statement code value of EXERR to accompany the DO RERUN statement.

When a DO RERUN statement is performed for a job (that is, the accompanying ON step and code criteria are satisfied), the previously run job is automatically assigned a final status of ENDED NOTOK, even if the job would have otherwise had a status of ENDED OK.

Example for DO RERUN

JOB: EF145TS  LIB CTM.PROD.SCHEDULE                     TABLE: EFPROD
COMMAND ===>                                          SCROLL===> CRSR
+-------------------------------------------------------------------+
  ==================================================================
  OUT                                                                
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS       
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP       
  SYSOUT OP   (C,D,F,N,R)                                       FROM 
  MAXRERUN      RERUNMEM                           INTERVAL    FROM  
  STEP RANGE         FR (PGM.PROC)          .          TO     .      
  ON PGMST COLLECT  PROCST          CODES S***   U****            A/O 
    DO RERUN                                                      
    DO                                                               
  ON PGMST          PROCST          CODES                        A/O 
    DO                                                               
  ON SYSOUT                                   FROM 001 TO 132    A/O  
    DO                                                                
  ON VAR                                                              
    DO                                                                
  SHOUT WHEN           TIME       +     DAYS   TO             URGN   
    MS                                                               
======= >>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<< ======
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                          11.17.00

DO SET: Post–processing Parameter

Assigns a value to an AutoEdit variable that can be used to set up the JCL of the next submission of a cyclic or rerun or restarted job, or to define a Global variable in the IOA Global Variable Database.

Figure 207 DO SET Parameter Format

(Optional) Type SET in the DO field and press Enter. The DO SET subparameter is described in Table 185.

Table 185 DO SET Subparameter

General Information for DO SET

A major advantage of using AutoEdit variables is that the JCL can be submitted with different values for different executions without actually changing the JCL.

There are two types of AutoEdit variables:

• System variables, which are assigned values by the system

• User-defined variables, for which the user must supply values; these variables can be either local or global

One method of supplying a value for a user-defined variable is by defining the variable and its value in a DO SET statement.

During job processing, the value is assigned at time of job submission. However, DO SET is a post-processing statement, which means that before it can be applied, its accompanying ON criteria must be satisfied in a job run.

Therefore, the DO SET statement is generally useful for supplying local user-defined variables for cyclic, rerun, or restarted jobs.

When the ON criteria of a DO SET statement that defines a local variable are satisfied during a job run, Control-M creates a SET VAR statement equivalent to the DO SET statement (that is, containing the same variable and value) in the subsequent job run.

At time of job submission, AutoEdit variables in the JCL are resolved in the order in which they appear in the JCL. By default, if an AutoEdit variable cannot be resolved, the job is not submitted. This default can be changed using an appropriate %%RESOLVE AutoEdit control statement.

DO SET statements can also be used to define and update Global Variables in the IOA Global Variable database. The database is updated as part of job post-processing, when the DO SET statement is processed. For more information on Global Variables, including Global Variable syntax, see JCL and AutoEdit Facility.

An unlimited number of DO SET statements can be specified.

JCL Setup and the AutoEdit facility are described in depth in JCL and AutoEdit Facility.

Differences between DO SET and SET VAR

DO SET and SET VAR statements are similar but have the following differences:

• Local variables in SET VAR statements are always applied before the job is submitted. DO SET is a post-processing statement that can only be applied after its accompanying ON step and code criteria are satisfied. This means that a local value specified in the DO SET statement can only be applied in the next submission of the job (specifically, for cyclic and rerun or restarted jobs).

• Global variables specified in a SET VAR statement are defined or updated in the IOA Global Variable database before job submission. Global variables specified in a DO SET statement are defined or updated in the IOA Global Variable database as part of job post-processing

• The SET VAR statement appears in each job scheduling definition. The DO SET statement does not appear unless specified. To specify a DO SET statement, type SET in an empty DO field and press Enter.

• In the SET VAR statement, the parameter value is specified after the keyword VAR. In the DO SET statement, the parameter value is specified after the keyword VAR=.

Example for DO SET

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE                    TABLE: PRODKPL
COMMAND ===>                                          SCROLL===> CRSR
+-------------------------------------------------------------------+
=====================================================================
OUT      PRDKPL01-ENDED-OK    ODAT +                                 
AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS         
RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP           
SYSOUT OP   (C,D,F,N,R)                                          FROM 
MAXRERUN     RERUNMEM                              INTERVAL    FROM   
STEP RANGE         FR (PGM.PROC)          .          TO        .      
ON PGMST ANYSTEP  PROCST          CODES S***   U****  C2000       A/O 
  DO IFRERUN   FROM $ABEND   .          TO          .       CONFIRM N
  DO RERUN                                                      
  DO SET       VAR= %%PARM=RESTART                              
  DO                                                                  
ON PGMST          PROCST          CODES                           A/O 
  DO                                                                 
ON SYSOUT                                      FROM 001 TO 132    A/O  
  DO                                                                
ON VAR                                                              
  DO                                                                
SHOUT WHEN           TIME       +     DAYS     TO              URGN   
  MS                                                                  
======= >>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<< ======
COMMANDS: EDIT, DOC, PLAN, JOBSTAT                           11.17.00

DO SHOUT: Post–processing Parameter

Specifies a message to be sent ("shouted") to a specific destination when a specific situation occurs.

Figure 209 DO SHOUT Parameter Format

(Optional) Type SHOUT in the DO field and press Enter. The DO SHOUT subparameters are described in Table 186.

Table 186 DO SHOUT Subparameters

General Information for DO SHOUT

The message is sent to the required destination when the accompanying ON statement criteria are satisfied.

DO SHOUT statements can also be defined in SMART Table Entities, where they are used in a manner similar to jobs.

The TO Subparameter

Specify TO=USERID-userid to write the message to the IOA Log file under the user ID specified in the parameter.

Specify TO=OPER[–n] to send the message to the operator console (route code n). If the n value is omitted, the message is sent to all consoles to which route codes 1 or 11 are assigned. For more detailed information regarding route codes, refer to the IBM publication Routing and Descriptor Codes, GC38-1102. Optionally, the message can also be sent to the Control-M/Enterprise Manager user, as described in "Shouting to Control-M/Enterprise Manager" below.

Specify TO=OPER2[–n] to send a highlighted, unrollable message to the operator console (route code n). If the n value is omitted, the message is sent to all consoles to which route codes 1 or 11 are assigned. For more detailed information regarding route codes, refer to the IBM publication Routing and Descriptor Codes, GC38-1102. Optionally, the message can also be sent to the Control-M/Enterprise Manager user, as described in "Shouting to Control-M/Enterprise Manager" below.

Specify TO=TSO-id or T-id to send the message to a groupid or logonid. The Shout facility first searches the IOA Dynamic Destination table for the specified ID. If the table contains an entry (groupid) that matches the value, the content of the entry is used as the target for the shouted message. The entire TO field is used. Therefore, when directing the message to a remote user, do not append Nn or Mm. Instead, do this in the IOA Dynamic Destination Table itself. For more information, see the description of the Dynamic Destination Table in the INCONTROL for z/OS Administrator Guide.

If no matching ID is found in the Dynamic Destination table, the Shout facility assumes the specified ID is a logonid. It then creates a TSO message that it hands over to MVS. MVS then sends the message to that logonid. (If the logonid does not exist, MVS cannot send the message, but no error message is generated.) When a second value is used, the message is sent to the TSO logonid in the specified computer or node (machine ID). To determine the machine ID under JES2, specify JES command $D MEMBER.

Specify TO=U-M: email_dest to send the message by e-mail to the recipient identified by the variable (email_dest). For more information about mail destinations, see the INCONTROL for z/OS Administrator Guide. The IOAPARM member includes DFLTSFFX, the mail address suffix, such as MAIL.DOMAIN.COM, the SMTP STC name, and the HOSTNAME. If installation parameter ATTSYSOT=Y, the job's SYSOUT will be attached to the e-mail message.

Specify TO=U-S:snmp_dest to send the SNMP trap (message) to the recipient identified by snmp_dest. For more information about mail destinations, see the INCONTROL for z/OS Administrator Guide.

Shouting to Control-M/Enterprise Manager

For Control-M to be able to shout to Control-M/Enterprise Manager, the following conditions must be satisfied at the site:

1. Control-M/Enterprise Manager must be installed and the ECS parameter must be set to Y in member IOAPARM in the IOA PARM library.

2. File MG2 (the Control-M/Enterprise Manager Shout File) must be defined.

3. The following parameters in the IOAPARM member in the IOA PARM library must be defined according to how messages are targeted to Control-M/Enterprise Manager:

   • If TO=OPER and TO=OPER2 messages must be sent to Control-M/Enterprise Manager, the OPER2ECS parameter must be set to Y (Yes). Otherwise, it must be set to N (No).

     When OPER2ECS is set to Y:

     • If these messages must also be sent to the MVS operator console, the OPER2CON parameter must also be set to Y (Yes).

     • If these messages must not also be sent to the MVS operator console, the OPER2CON parameter must also be set to N (No).

   • If TO=U-ECS messages must be sent to Control-M/Enterprise Manager, the UECS2ECS parameter must be set to Y (Yes); otherwise, it must be set to N (No). Regardless of the value of this parameter, these messages are also sent to Control-M and the IOA Log.

Once the above conditions are satisfied, messages can be shouted to Control-M/Enterprise Manager by specifying a destination of TO=OPER or TO=OPER2 (without a route code qualifier), or TO=U-ECS.

Such messages are then placed by Control-M in the M2G file. Once the shouted message is in the M2G file, the Control-M Application Server reads the file and sends the message to the Control-M/Enterprise Manager user.

The URGENCY Subparameter

The URGENCY value indicates the urgency level of the message.

In addition, if the destination is USERID-userid (or U-userid), the user can control, according to urgency, which messages are displayed when the IOA Log file is accessed. Urgent and very urgent messages are highlighted on the screen. For more details, see IOA Log Facility.

Differences between SHOUT and DO SHOUT

SHOUT and DO SHOUT statements have the following differences:

• A DO SHOUT statement is applied only if the accompanying ON criteria are satisfied. Therefore a DO SHOUT statement does not contain subparameters for specifying when to perform the shout.

  By contrast, a SHOUT statement requires that a value be specified in subparameter WHEN indicating when to shout the message. Messages can be shouted when the job ends OK or NOTOK, when the job is late for submission or completion, or when the job runs too long.

• A SHOUT statement appears in each job scheduling definition. A DO SHOUT statement does not appear unless specified. To specify a DO SHOUT statement, type SHOUT in an empty DO field and press Enter.

• The SHOUT URGN subparameter is equivalent to the DO SHOUT URGENCY subparameter.

• The SHOUT MS subparameter is equivalent to the DO SHOUT subparameter.

Example for DO SHOUT

JOB: SACALC01 LIB CTM.PROD.SCHEDULE                      TABLE: SALARY
COMMAND ===>                                           SCROLL===> CRSR
+----------------------------------------- --------------------------+
  ====================================================================
  OUT                                                                 
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS        
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP         
  SYSOUT OP   (C,D,F,N,R)                                        FROM 
  MAXRERUN     RERUNMEM                        INTERVAL       FROM    
  STEP RANGE         FR (PGM.PROC)          .          TO       .     
  ON PGMST ANYSTEP  PROCST          CODES JNRUN                    A/O 
    DO SHOUT     TO  TSO-U0014          URGENCY U                 
     = *** JCL ERROR IN SALARY JOB ***                            
    DO                                                                
  ON PGMST          PROCST          CODES                         A/O 
    DO                                                                
  ON SYSOUT                                    FROM 001 TO 132    A/O  
    DO                                                                
  ON VAR                                                              
    DO                                                                
  SHOUT WHEN           TIME       +     DAYS     TO            URGN   
    MS                                                                
======= >>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<< ======
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                           11.17.00

DO STOPCYCL: Post-Processing Parameter

Stops recycling a cyclic task.

Figure 211 DO STOPCYCL Parameter Format

The DO STOPCYCL statement has no subparameters. Type the word STOPCYCL in the DO field and press Enter.

General Information for DO STOPCYCL

DO STOPCYCL is intended for use with all cyclic tasks (cyclic job, cyclic STC, emergency cyclic job and emergency cyclic STC). It interrupts a job cycle after the current run, so that once the job completes its current run, it does not run again. This parameter does not change the status (OK or NOTOK) assigned to job during the last cycle.

After DO STOPCYCL has interrupted a job, commands RERUN or RESTART can be used in the Active Environment screen to continue the job cycle from where it stopped. Commands RERUN and RESTART resume the stopped cyclic tasks without waiting for a cycling interval to occur. After the job restarts, it continues its normal cyclic interval as before.

Example for DO STOPCYCL

JOB: SACALC01 LIB CTM.PROD.SCHEDULE                      TABLE: SALARY
COMMAND ===>                                           SCROLL===> CRSR
+--------------------------------------------------------------------+
  ====================================================================
  OUT                                                                 
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS        
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP         
  SYSOUT OP   (C,D,F,N,R)                                         FROM 
  MAXRERUN     RERUNMEM                        INTERVAL 003   FROM    
  STEP RANGE         FR (PGM.PROC)          .       TO       .        
  ON PGMST ANYSTEP  PROCST          CODES NOTOK                    A/O 
    DO STOPCYCL                                                   
    DO                                                                
  ON PGMST          PROCST          CODES                          A/O 
    DO                                                                
  ON SYSOUT                                     FROM 001 TO 132    A/O  
    DO                                                                
  ON VAR                                                              
    DO                                                                
  SHOUT WHEN           TIME       +     DAYS     TO            URGN   
    MS                                                                
======= >>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<< ======
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                           11.17.00

DO SYSOUT: Post-Processing Parameter

Controls handling of job output if the accompanying ON step and code criteria are satisfied.

Figure 213 DO SYSOUT Parameter Format

(Optional) Type the word SYSOUT in the DO field and press Enter. The DO SYSOUT subparameters are described in Table 187.

Table 187 DO SYSOUT Subparameters

General Information for DO SYSOUT

The Control-M monitor, unless otherwise instructed, leaves the job SYSOUT in HELD class in the output queue.

The DO SYSOUT parameter is used to request additional handling of these held sysouts when the accompanying ON criteria are satisfied.

The Control-M monitor sends all SYSOUT handling requests to JES, which processes the instructions. If, however, the copying of sysouts to a file is requested (option F), Control-M requests the sysouts from JES and then Control-M directly writes the sysouts to the file.

Since only one SYSOUT statement can be defined in a job scheduling definition, DO SYSOUT statements can be used, as follows, to specify additional sysout handling instructions when the job ends OK:

• To define DO SYSOUT statements that operate like a SYSOUT statement (that is, that operate only when the job ends OK), define their accompanying ON statement with PGMST value ANYSTEP and code value OK.

• The interrelationship between multiple SYSOUT operations (by SYSOUT and DO SYSOUT statements) is described in Multiple SYSOUT Operations.

DO SYSOUT Handling Operations

The SYSOUTs that are affected by SYSOUT handling operations are determined by whether the SYSOUTs are under JES2 or JES3, as described in the following table.

Table 188 Varying Effect of SYSOUT Handling Operations

SYSOUT handling operations are listed below:

• Copying SYSOUTs to a file (OPT=F)

  The SYSOUTs of the job are copied (not moved) to the file specified in the data subparameter.

  The file name specified in the data subparameter can contain AutoEdit System variables, and user-defined AutoEdit variables that are defined in the job scheduling definition or the IOA Global Variable database, or are loaded into AutoEdit cache. If the AutoEdit variables cannot be resolved, the sysout is not copied.

  Control-M allocates the file with DISP=(NEW,CATLG,DELETE) using the unit and space attributes specified in the Control-M installation parameters. While the block size (BLKSIZE) is automatically calculated by Control-M, the logical record length (LRECL) is copied from the input SYSOUT file. The maximum LRECL allowed is 256 characters.

  SYSOUTs can be archived by copying them. However, to reduce overhead, this method is recommended only for small sysouts.

• Deleting SYSOUTs (OPT=D)

  The SYSOUTs of the job are deleted (purged) from the output queue.

  This operation works on all SYSOUTs under JES2 or JES3 (regardless of held status or class) unless otherwise restricted by the FRM subparameter.

• Releasing SYSOUTs (OPT=R)

  The SYSOUTs of the job are released for printing.

• Changing the class of SYSOUTs (OPT=C)

  The SYSOUTs of the job are changed to the output class specified in the data subparameter. Ensure that you specify a meaningful target output class.

  Note the following points:

  • Changing a SYSOUT class to a non-held class does not release the SYSOUT because the SYSOUT attributes do not change (due to JES logic).

  • To ensure that the SYSOUT is released, use DO SYSOUT statements to release the SYSOUT after changing its class.

    Copy

    DO SYSOUT OPT C PRM R FRM A
    DO SYSOUT OPT R PRM FRM A

  • Changing a SYSOUT class to a dummy class does not purge the SYSOUT because the SYSOUT attributes do not change (due to JES logic).

  • To save the original MSGCLASS of a job and to restore it at output processing time, specify a data value of *. The SYSOUTs are changed to the original class of the job.

• Moving SYSOUTs to a new destination (OPT=N)

  The SYSOUTs of the job are moved to the output destination specified in the data subparameter. Ensure that you specify a meaningful target output destination.

Multiple SYSOUT Operations

If multiple DO SYSOUT (or SYSOUT/DO SYSOUT) operations are not specified for the same FROM class, the order in which the operations are performed is not significant.

However, if different DO SYSOUT (or SYSOUT/DO SYSOUT) operations affect the same FROM class, or if multiple operations are specified without a FROM class, the order and method of implementation is significant.

Control-M merges different operations for the same FROM class into a combined instruction to JES. Likewise, Control-M merges different operations without a FROM class into a combined instruction to JES.

Operations without a specified FROM class treat the entire held sysout as a whole unit, and are therefore not merged with sysout handling requests for a specific FROM class.

JES does not necessarily process multiple SYSOUT handling instructions in the order they are issued by Control-M. Therefore, the processing results can vary if the merged instructions to JES include both FRM equals a specified class and FRM equals blank.

BMC therefore recommends that you do not include in a job scheduling definition both "FROM class" and "no FROM class" sysout handling instructions that become operational under the same situations.

When Control-M merges a set of operations into a combined instruction, some operations override or cancel other operations, and some operations are performed along with other operations. This is described below.

Operation Merging and Performance

Control-M performs all copy to file operations (option F) first.

After performing all copy to file operations, Control-M merges all operations performed on a specific FROM class.

After merging operations on specific FROM classes, Control-M merges the operations performed on the SYSOUT as a whole (where the FRM subparameter is set to blank).

Control-M then passes the merged sets of instructions to JES for processing.

The resulting combination of operations can vary depending on whether the operation that was merged with a DO SYSOUT operation is a SYSOUT operation or another DO SYSOUT operation.

Generally, DO SYSOUT operations override, or are performed along with, SYSOUT statements.

The following chart and the accompanying numbered explanations indicate the result of merging multiple DO SYSOUT statements. Note the following points about the chart in Figure 214:

• Operations are indicated by their symbols (F,D,R,C,N), at the top and side of the chart. The operations at the top of the chart represent DO SYSOUT operations. The operations at the side of the chart represent SYSOUT or DO SYSOUT operations.

• Merging and processing operations are grouped, and explained, based on operation type. Groups are delimited by lines, and are numbered (from 1 through 4). Within each group, operations are delimited by periods. Explanations of each group are provided, by number, following the chart.

• The handling of the combination of operations is generally reflected in the chart by a single operation code (such as D) or pair of operation codes, such as FR. In some cases, the operations are merged. This is indicated by the word "merged." In some cases, handling depends on whether the combination consists of both a SYSOUT and a DO SYSOUT statement, or multiple DO SYSOUT statements (that is, without a SYSOUT statement). This is indicated by an asterisk (*). These are all explained in the numbered explanations that follow the chart.

Figure 214 Effect of Merging Multiple SYSOUT Statements

The order of precedence in which Control-M processes and merges operations is as follows:

1. DO SYSOUT=F

   Copy to file operations are performed first (directly by Control-M) for DO SYSOUT statements, regardless of whether FROM class is specified. Other operations are then performed.

2. DO SYSOUT=D (Delete)

   This operation supersedes all other DO SYSOUT operations (except copy to file operations described above). Superseded operations are ignored, that is, they are not performed.

3. DO SYSOUT combinations of R, C and N

   In general, combinations of R, C, and N requests are merged, that is, they are all performed. The exceptional cases indicated in the chart are described below:

   • If multiple C requests come from DO SYSOUT statements, perform only one of the requests. Normally, do not specify this combination.

   • If multiple N requests come from DO SYSOUT statements, perform the request that occurs first.

Differences between SYSOUT and DO SYSOUT

SYSOUT and DO SYSOUT statements have the following differences:

• The SYSOUT statement is applied only if the job ends OK. DO SYSOUT statements are associated with accompanying ON statements and are applied only if the accompanying ON step and code criteria are satisfied.

• A SYSOUT statement is displayed in each job scheduling definition. A DO SYSOUT statement is not displayed unless requested. To request a DO SYSOUT statement, type SYSOUT in an empty DO field and press Enter.

• Only one SYSOUT statement can be defined in the job scheduling definition. An unlimited number of DO SYSOUT statements can be requested.

• The SYSOUT OP subparameter is equivalent to the DO SYSOUT OPT subparameter.

• The SYSOUT data subparameter is equivalent to the DO SYSOUT PRM subparameter.

• The SYSOUT FROM subparameter is equivalent to the DO SYSOUT FRM subparameter.

Examples for DO SYSOUT

JOB: SACALC01 LIB CTM.PROD.SCHEDULE                       TABLE: SALARY
COMMAND ===>                                            SCROLL===> CRSR
+---------------------------------------------------------------------+
  OUT                                                                 
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS         
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP          
  SYSOUT OP   (C,D,F,N,R)                                         FROM 
  MAXRERUN     RERUNMEM                             INTERVAL   FROM    
  STEP RANGE         FR (PGM.PROC)          .          TO        .     
  ON PGMST ANYSTEP  PROCST          CODES OK                        A/O 
    DO SYSOUT    OPT D PRM                                          FRM 
  ON PGMST STEP02   PROCST          CODES C005*                    A/O 
    DO OK                                                              
    DO SYSOUT    OPT R PRM                                         FRM 
    DO                                                                 
  ON PGMST ANYSTEP  PROCST          CODES U**** S****               A/O 
    DO SYSOUT    OPT C PRM D                                        FRM 
    DO                                                                 
  ON PGMST          PROCST          CODES                           A/O 
    DO                                                                 
  ON SYSOUT                                      FROM 001 TO 132    A/O  
    DO                                                                
  ON VAR                                                              
    DO                                                                
  SHOUT WHEN           TIME       +     DAYS     TO             URGN   
    MS                                                                 
======= >>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<< =====
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                            11.17.00

JOB: GPLUPDT1 LIB CTM.PROD.SCHEDULE                      TABLE: PRODGPL
COMMAND ===>                                            SCROLL===> CRSR
+---------------------------------------------------------------------+
  =====================================================================
  OUT                                                                  
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP          
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS         
  SYSOUT OP   (C,D,F,N,R)                                          FROM 
  MAXRERUN     RERUNMEM                            INTERVAL    FROM    
  STEP RANGE         FR (PGM.PROC)          .          TO        .     
  ON PGMST ANYSTEP  PROCST          CODES *****                    A/O 
    DO SYSOUT   OPT F PRM GPL.%%JOBNAME.D%%ODATE.N%%JOBID.T%%TIME FRM X
    DO                                                                 
  ON PGMST ANYSTEP  PROCST          CODES OK                        A/O 
    DO SYSOUT    OPT D PRM                                        FRM X
    DO SYSOUT    OPT R PRM                                        FRM D
    DO                                                                 
  ON PGMST ANYSTEP  PROCST          CODES NOTOK                    A/O 
    DO SYSOUT    OPT D PRM                                        FRM D
    DO                                                                 
  ON PGMST          PROCST          CODES                           A/O 
    DO                                                                 
  ON SYSOUT                                      FROM 001 TO 132    A/O  
    DO                                                                
  ON VAR                                                              
    DO                                                                
  SHOUT WHEN           TIME       +     DAYS     TO             URGN   
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                            11.17.00

DOC: General Job Parameter

Detailed job documentation. This field can be displayed or hidden by request.

Figure 217 DOC Parameter Format

(Optional) Upon filling in a DOC line with text and pressing Enter, a new DOC line is opened for specifying additional documentation text.

General Information for DOC

DOC lines are used for specifying job documentation.

Upon entry to the job scheduling definition, DOC lines are displayed only if the value Y was specified in field SHOW JOB DOCUMENTATION in the Scheduling Definition Facility entry panel.

Command DOC can be used in the job scheduling definition to toggle between the display and non display of job documentation.

The information specified in the DOC lines is automatically converted to uppercase and saved in the member and library specified in the DOCMEM and DOCLIB parameters. This member can also be edited directly by ISPF edit.

When modifying DOC lines in the job scheduling definition, text must be left in at least one DOC line in order to save the modifications. Changes resulting in an empty DOCMEM member are not saved when exiting the job scheduling definition.

For more information regarding job documentation, including the saving of job documentation changes, see Job Documentation.

Example for DOC

JOB: BACKPL02 LIB CTM.PROD.SCHEDULE                       TABLE: BACKUP
COMMAND ===>                                            SCROLL===> CRSR
+---------------------------------------------------------------------+
  MEMNAME BACKPL02    MEMLIB   CTM.PROD.JOBLIB                         
  OWNER   M44         TASKTYPE JOB    PREVENT-NCT2 Y DFLT  N           
  APPL    APPL-L                      GROUP BKP-PROD-L                 
  DESC    DAILY BACKUP OF SPECIAL FILES FROM APPL-L                    
  OVERLIB CTM.OVER.JOBLIB                                   STAT CAL   
  SCHENV                         SYSTEM ID                  NJE NODE   
  SET VAR                                                             
  CTB STEP AT         NAME            TYPE                             
  DOCMEM  BACKPL02    DOCLIB   CTM.PROD.DOC                            
  =====================================================================
  DOC THIS JOB BACKS UP "L" FILES. IT PERFORMS THE FOLLOWING STEPS:
  DOC 1:   VERIFY SPACE REQUIREMENTS                              
  DOC 2-5: BACKUP THE FILES                                       
  DOC 6:   RECATALOG THE NEW FILES                                
  DOC 7:   PRINT THE SHORT-VERSION LISTING REPORT                 
  DOC                                                             
  ====================================================================
  DAYS ALL                                                      DCAL   
                                                                AND/OR 
  WDAYS                                                         WCAL   
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                            11.17.00

DOCLIB: General Job Parameter

Name of the library in which the member specified in DOCMEM resides.

Figure 219 DOCLIB Parameter Format

(Optional) The DOCLIB parameter identifies a valid data set name of 1 through 44 characters. The default is either defined at time of installation or is blank.

General Information for DOCLIB

The library can be any standard partitioned data set. The record length must be 80.

Any number of documentation libraries can be used at a site. However, only one documentation library can be specified in each job scheduling definition.

Example for DOCLIB

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE                             TABLE: PRODKPL
COMMAND ===>                                                    SCROLL===> CRSR
+-----------------------------------------------------------------------------+
  MEMNAME PRDKPL01    MEMLIB   CTM.PROD.JCL                                 
  OWNER   SYS1        TASKTYPE JOB    PREVENT-NCT2 Y DFLT  N                
  APPL    KPL                         GROUP PROD-KPL                        
  DESC    DAILY PRODUCTION - START OF APPL-PROD-KPL                         
  OVERLIB                                                   STAT CAL        
  SCHENV                         SYSTEM ID                  NJE NODE        
  SET VAR                                                                   
  CTB STEP AT         NAME            TYPE                                  
  DOCMEM  PRDKPL01    DOCLIB   CTM.PROD.DOC                        
  ===========================================================================
SCHEDULE RBC                                                                
RELATIONSHIP (AND/OR) O                                                     
DAYS  01                                                       DCAL           
                                                                   AND/OR   
WDAYS                                                        WCAL           
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y       
DATES                                                                       
CONFCAL          SHIFT       RETRO N MAXWAIT 04   D-CAT                     
MINIMUM PDS 
DEFINITION ACTIVE FROM UNTIL
  ===========================================================================
  IN       START-DAILY-PROD-KPL ODAT                                        
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                    11.17.00

DOCMEM: General Job Parameter

Name of the member that contains job documentation.

Figure 221 DOCMEM Parameter Format

(Optional) DOCMEM identifies a valid member name of 1 through 8 characters. The default is either defined during installation or is blank.

General Information for DOCMEM

DOCMEM identifies a member that is in the library identified by the DOCLIB parameter. This member is used to save detailed documentation written in the DOC lines of the Job Scheduling Definition screen (or Zoom screen).

When you enter the Job Scheduling Definition screen for the first time, DOCMEM defaults to the value of MEMNAME. You can change this value, but it is recommended that you not do so.

Example for DOCMEM

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE                             TABLE: PRODKPL
COMMAND ===>                                                    SCROLL===> CRSR
+-----------------------------------------------------------------------------+
  MEMNAME PRDKPL01    MEMLIB   CTM.PROD.JCL                                
  OWNER   SYS1        TASKTYPE JOB    PREVENT-NCT2 Y DFLT  N               
  APPL    KPL                         GROUP PROD-KPL                       
  DESC    DAILY PRODUCTION - START OF APPL-PROD-KPL                        
  OVERLIB                                                   STAT CAL       
  SCHENV                         SYSTEM ID                  NJE NODE       
  SET VAR                                                                  
  CTB STEP AT         NAME            TYPE                                 
  DOCMEM  PRDKPL01  DOCLIB   CTM.PROD.DOC                                
  ===========================================================================
SCHEDULE RBC                                                                
RELATIONSHIP (AND/OR) O                                                     
DAYS                                                         DCAL           
                                                                   AND/OR   
WDAYS                                                        WCAL           
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y       
DATES                                                                       
CONFCAL          SHIFT       RETRO N MAXWAIT 04   D-CAT                     
MINIMUM PDS  
DEFINITION ACTIVE FROM UNTIL
  ===========================================================================
  IN       START-DAILY-PROD-KPL ODAT                                       
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                    11.17.00

DUE OUT: Runtime Scheduling Parameter

Time and date by which a job must finish executing.

Figure 223 DUE OUT Parameter Format

(Optional) The format for the DUE OUT TIME parameter is hhmm, where:

• hh is the hour the job is due out (based on a 24-hour clock)

• mm is the minute the job is due out

If the DUE OUT DAYS parameter is entered, the value must be a number between zero and 120. This is the relative number of days by which the job must finish execution. For example, assume that the ODATE is September 5, DUE OUT TIME is 17:00, and DUE OUT DAYS is 2. This means that the job must finish executing by Control-M working date of September 7 at 17:00.

General Information for DUE OUT

The DUE OUT parameters are used to specify the date and time by which the job must finish executing.

When specified in a SMART Table Entity, the DUE OUT parameters are used to specify the date and time by which all the jobs contained in the SMART Table must finish executing.

When two jobs with the same priority are available for submission, Control-M submits the job with the earlier DUE OUT date and time first.

When a DUE OUT date and time is specified, the Control-M monitor can calculate a DUE IN date and time for the job.

The DUE IN date and time are the recommended date and time by which the job must be submitted in order to finish executing by the DUE OUT date and time.

If the DUEINCHK parameter in the CTMPARM member in the IOA PARM library has been set to No, the job is always submitted, no matter what values are present in the DUE IN date and time.

If the DUEINCHK parameter in the CTMPARM member in the IOA PARM library has been set to Yes, job submission depends on the DUE IN date and time:

• If the DUE IN date of a job has passed, the job is never submitted.

• If the DUE IN date is not present, and the DUE IN time has passed, the job must wait until the next day to be submitted.

To calculate the DUE IN time, the Control-M monitor subtracts the anticipated elapse time of the job from the DUE OUT time. The anticipated elapse time is the average of the execution times of the job recorded in the Control-M Statistics file.

If DUE OUT date is present, the DUE IN date is calculated as follows:

• The DUE IN date is equal to the DUE OUT date.

• If, when you move forward on the physical clock from the New Day Processing time, you arrive at the DUE OUT TIME before you arrive at the DUE IN time, it means that New Day processing falls between the DUE IN TIME and the DUE OUT TIME. In this case, one day is subtracted from the DUE IN DATE.

If DUE OUT TIME is not specified, the default DUE OUT TIME is the last minute of the working day.

Automatic adjustment of DUE OUT date and time can be requested from the Job Dependency Network screen.

For more information, see Automatic Job Flow Adjustment, and Job Dependency Network Screen. For an explanation of how DUE OUT affects job submission in the QUIESCE command, see the description of setting a planned shutdown time in the INCONTROL for z/OS Administrator Guide.

Please note that when specifying a DUE OUT date, the correct MAXWAIT parameter value must be specified. For details, see MAXWAIT: Basic Scheduling Parameter.

Example for DUE OUT

JOB: DISKLOG2 LIB CTM.PROD.SCHEDULE                             TABLE: ADABAS
COMMAND ===>                                                    SCROLL===> CRSR
+-----------------------------------------------------------------------------+
  SCHENV                         SYSTEM ID                  NJE NODE        
  SET VAR                                                                   
  CTB STEP AT         NAME            TYPE                                  
  DOCMEM  DISKLOG2    DOCLIB   CTM.PROD.DOC                                 
  ===========================================================================
SCHEDULE RBC                                                                
RELATIONSHIP (AND/OR) O                                                     
DAYS                                                         DCAL           
                                                                   AND/OR   
WDAYS                                                        WCAL           
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y       
DATES                                                                       
CONFCAL          SHIFT       RETRO N MAXWAIT 99   D-CAT                     
MINIMUM PDS  
DEFINITION ACTIVE FROM UNTIL
  ===========================================================================
  IN       DBA-CLEAN-LOG-2      ****                                        
  CONTROL                                                                   
  RESOURCE TAPE                 0001                                        
  PIPE                                                                      
  FROM TIME         +     DAYS    UNTIL TIME      +     DAYS  
  DUE OUT TIME 0600 + 2   DAYS    PRIORITY     SAC    CONFIRM 
  TIME ZONE:                                                  
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                    17.14.10

END-TABLE: Post–processing Parameter

Specifies the job as an end point for the SMART table.

Figure 224a END-TABLE Parameter Format

OUT
AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS
RETENTION:  # OF DAYS TO KEEP      # OF GENERATIONS TO KEEP
SYSOUT OP   (C,D,F,N,R)                                              FROM
MAXRERUN      RERUNMEM             END-TABLE Y
CAPTURE BY   (W - WORD / C - CHAR)

(Optional) Valid values are indicated in the following table.

Table 188a END-TABLE Parameter Values

After the end point job completes, no additional jobs in the SMART table will be submitted and the table is marked as complete when the jobs, which are still executing, end.

Jobs remain in WAIT-SCHEDULE status if they were not submitted before the table was marked as complete.

If jobs in the SMART table, which were submitted before the table was marked as complete, end OK, the table is marked OK. Otherwise, the table is marked as NOT-OK.

GROUP: General Job Parameter

Group to which a job belongs.

Figure 225 GROUP Parameter Format

The GROUP parameter identifies a group name of 1 through 20 characters. Only trailing blanks are allowed.

• In a table whose jobs are scheduled individually, the GROUP parameter is optional. The same value does not have to be specified for all jobs in the table.

• In a SMART Table, only jobs whose GROUP name is blank, inherit the GROUP name specified in the SMART Table Entity. Jobs with a GROUP name specified will not inherit the GROUP name specified in the SMART Table Entity.

General Information for GROUP

The GROUP parameter affects the retrieval and display of information. It does not affect job scheduling.

Job Scheduling of SMART Tables

When a SMART Table is created, specifying a value for the GROUP parameter in the SMART Table Entity is optional. This value is only applied to job scheduling definitions if the GROUP parameter of the job is blank.

Jobs in a SMART Table cannot be individually ordered. Jobs in this type of table can only be ordered as a unit, though they can be individually forced.

Before jobs in the SMART Table can be scheduled, the set of jobs must be eligible for scheduling, meaning that a set of basic scheduling criteria in the SMART Table Entity must be satisfied.

Basic scheduling criteria, runtime scheduling criteria, and post-processing parameters in the SMART Table Entity apply to all scheduled jobs in the SMART Table.

For more information, see Handling of Jobs and "Scheduling Jobs in SMART Tables" in Job Production Parameters.

Retrieving and Displaying Information

The GROUP parameter can be used as a selection criteria that can make retrieval and display of information more efficient.

For example, display of information in the Active Environment screen can be limited to jobs belonging to a specific GROUP.

The group name appears in all important messages relating to the jobs in the GROUP.

Example for GROUP

JOB: OPERCOMP LIB CTM.PROD.SCHEDULE                             TABLE: OPER
COMMAND ===>                                                    SCROLL===> CRSR
+-----------------------------------------------------------------------------+
  MEMNAME OPERCOMP    MEMLIB   CTM.PROD.JCL                                 
  OWNER   SYS1        TASKTYPE JOB    PREVENT-NCT2 Y DFLT  N                
  APPL    OPER                        GROUP MAINTENANCE             
  DESC    JOB RUN ON THE 1ST OF THE MONTH                                   
  OVERLIB                                                   STAT CAL        
  SCHENV                         SYSTEM ID                  NJE NODE        
  SET VAR                                                                   
  CTB STEP AT         NAME            TYPE                                  
  DOCMEM  OPERCOMP    DOCLIB   CTM.PROD.DOC                                 
  ===========================================================================
SCHEDULE RBC                                                                
RELATIONSHIP (AND/OR) O                                                     
DAYS    01                                                     DCAL           
                                                                   AND/OR   
WDAYS                                                        WCAL           
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y       
DATES                                                                       
CONFCAL          SHIFT       RETRO N MAXWAIT 04   D-CAT                     
MINIMUM PDS  
DEFINITION ACTIVE FROM UNTIL
  ===========================================================================
  IN                                                                        
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                    11.17.00

IN: Runtime Scheduling Parameter

Prerequisite conditions that must be satisfied before the job can run.

Figure 227 IN Parameter Format

(Optional) A maximum of two prerequisite conditions can be specified in each standard IN line. One prerequisite condition can be specified in each long IN line. When you specify the second prerequisite condition in a standard IN line, or one prerequisite condition in a long IN line, and press Enter, a new IN line is opened for specifying additional prerequisite conditions. For more information, see Specifying Long IN Condition Names.

Each specified prerequisite condition consists of the mandatory subparameters described in Table 189.

Table 189 IN Subparameters

General Information for IN

A job cannot be submitted unless all the prerequisite condition criteria specified in the IN statements have been satisfied.

Prerequisite conditions are usually used to establish job dependencies or to ensure manual intervention when required:

• To establish job dependency, define a prerequisite condition in an OUT or DO COND statement in the job that must run first, and in an IN statement in the job that must run afterwards.

  The job containing a prerequisite condition in its IN statement is not submitted unless that prerequisite condition has been added manually or by the job containing the OUT or DO COND statement.

  • An OUT statement adds the prerequisite condition if the job ends OK.

  • The DO COND statement adds the prerequisite condition if the step and code event criteria specified in the accompanying ON statement are satisfied.

• If the IN prerequisite condition can only be satisfied by manual intervention (for example, TAPE1-ARRIVED is set by the operator after an external tape arrives on-site), performance of the required manual intervention before job submission can be ensured.

OUT and DO COND statements can also be used to delete prerequisite conditions that are no longer needed. If an IN prerequisite condition for a job is not an IN prerequisite condition for any other job, you can use the OUT statement of the job to delete the prerequisite condition after the job ends OK.

The following are examples of prerequisite conditions:

MS-ACTIVE
JOB_PAYCALC_ENDED_OK
TAPE1_LOADED

All prerequisite conditions are created with a date reference. When specifying a prerequisite condition as an IN condition, you must specify the date for the condition. Only a prerequisite condition with the specified date can satisfy the IN requirement.

For more information regarding prerequisite conditions, see OUT: Post–processing Parameter, ON Statements: Post–processing Parameter, and DO COND: Post–processing Parameter, and see Prerequisite Conditions.

Specifying Long IN Condition Names

Regular prerequisite conditions are not more than 20 characters in length. If you want to specify a longer condition name, up to 39 characters in length, enter the string LONG in the date reference field of an empty IN condition line. An (L) appears at the beginning of the line. If the field already contains data, entering the string LONG will open a new long IN condition parameter, with (L) appearing at the beginning of the line. You can now insert a long condition name, as illustrated in Figure 228 below.

Specify SHRT in the date reference field to revert back to condition names of standard length.

Figure 228 Long IN Condition

JOB: J13      LIB   CTMP.V610.SCHEDULE                         TABLE: REV1  
COMMAND ===>                                                   SCROLL===> CRSR
+-----------------------------------------------------------------------------+
  IN        CTMLDNRS-NMIS-OK  ODAT     CTMLDNRS-NMIS-OK1 ODAT  
        (L) THIS-IS-A-LONG-IN-CONDITION-NAMEXXXXXXX      ODAT  
  CONTROL                                                                   
  RESOURCE                                                                  
  PIPE                                                                      
  FROM TIME         +     DAYS    UNTIL TIME      +     DAYS  
  DUE OUT TIME      +     DAYS    PRIORITY     SAC    CONFIRM 
  TIME ZONE:                                                                
  ============================================================================
  OUT        J1-ENDED                 ODAT +                                
  AUTO-ARCHIVE Y              SYSDB      Y    MAXDAYS      MAXRUNS          
  RETENTION:  # OF DAYS TO KEEP          # OF GENERATIONS TO KEEP           
  SYSOUT OP   (C,D,F,N,R)                                               FROM
  MAXRERUN      RERUNMEM                               INTERVAL      FROM   
  STEP RANGE         FR (PGM.PROC)                         TO       .       
  ON PGMST          PROCST              CODES                            A/O
    DO                                                                      
  ON SYSOUT                                           FROM 001 TO 132    A/O  
    DO                                                                
  ON VAR                                                              
    DO                                                                
  SHOUT WHEN LATE      TIME 1300  +     DAYS     TO TS0-N88          URGN R  
    MS BBB                                                                  
  SHOUT WHEN           TIME       +     DAYS     TO                  URGN   
    MS                                                                      
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                    09.06.50

Logical Relations between Multiple Conditions

The IN condition parameter differs from other parameters that may be defined more than once.

Where there are multiple IN condition definitions, they are not independent parameters, as might at first appear. Control-M takes them together and treats them as a logical expression consisting of a series of connected terms, which appear as condition names.

Control-M resolves every such condition to a value of "True" or "False," and then evaluates the whole expression, using the logical operators which may have been specified as part of each condition name. The run-time criteria for prerequisite IN conditions are only satisfied if the overall value of the expression is calculated as "True". A condition name is evaluated as "True" if the name of that condition appears in the IOA Conditions file.

Conditions may be added to or deleted from the IOA Conditions file automatically or manually. Some typical means of adding and/or deleting conditions are:

• the Control-M Monitor, by means of OUT or DO COND statements

• the IOA Conditions/Resources screen

• the IOA Manual Conditions screen

• the IOACND or IOACLND batch utilities

The following types of logical operator can be used to connect condition names:

• unitary

• binary

• group

Operators: Unitary

The logical NOT is the only unitary operator. It is represented in the condition name by the symbol ¬ (Hex 5f) or \ (Hex e0). Conditions that have this type of symbol associated with them are called "inverted" conditions. An inverted condition is only "True" if that condition does not exist on the IOA Conditions File.

Operators: Binary

The following are the binary operators:

• logical AND
  This is implicit, and has no explicit representation in the condition name.

• logical OR, represented by the symbol | (Hex 4f)

Where an expression contains conditions connected by an AND operator, both must be present in the IOA Conditions File for the expression to be "True".

An expression that contains conditions connected by an OR operator is "True" if either expression is present in the IOA Conditions File.

Because logical OR operators are expressed as part of the condition name,

• all conditions connected by the logical OR must specify the OR symbol in their condition name

  This means that, for example, expressions of the form

  A|B

  must not be specified because their meaning is unclear, even though they will not be syntactically rejected. In reality, because condition nameA does not have an OR symbol attached to it, no logical OR connection exists between A and B, and the OR symbol attached to condition nameB is ignored. The correct way to specify "ConditionA OR ConditionB" is

  (|A|B)

• all condition names that specify an OR symbol are processed first, before those specifying an AND symbol

  This has the effect of creating implicit parentheses among the terms of the expression (explained under "Operators: Group" below); the terms of the expression may also be rearranged.

  The expression

  |B|CD|E

  is processed as if the expression had been

  ( |B|C|E )D

Operators: Group

The group operator is the pair of parentheses, Open, represented by the symbol ( , and Close, represented by the symbol ) . These must always appear in matched pairs. Parentheses affect the order in which the other logical operators are applied to the terms of the expression. Always specify parentheses when coding an expression that contains different logical operators, to ensure that the terms are combined in the way you want.

Various combinations of logical operators are permitted, subject to the following limitations:

• only one level of parenthesis nesting is allowed

• double NOT operators are not supported

• an open parenthesis preceded by a NOT operator is not allowed

As in standard logic (de Morgan’s Rules), the following expressions express logical equivalence:

A    (|B    |C)          and          |(A    B)    |(A    C)
|A    |(B    C)          and           (|A    |B)    (|A    |C)
A    ¬ A   is always "False".

IN            |A            B
               ¬C         |¬D
             |(¬E            F)

Examples for IN

The following are examples of the IN parameter:

JOB: EBDRPT1A LIB CTM.PROD.SCHEDULE                            TABLE: EBDPROD
COMMAND ===>                                                   SCROLL===> CRSR
+----------------------------------------------------------------------------+
  APPL    EBD                         GROUP EBD-PRODUCTION                  
  DESC    EBD PRODUCTION SALARY REPORTS                                     
  OVERLIB                                                   STAT CAL        
  SCHENV                         SYSTEM ID                  NJE NODE        
  SET VAR                                                                   
  CTB STEP AT         NAME            TYPE                                  
  DOCMEM  EBDRPT1A    DOCLIB   CTM.PROD.DOC                                 
  ============================================================================
SCHEDULE RBC                                                                
RELATIONSHIP (AND/OR) O                                                     
DAYS   0.15                                                      DCAL           
                                                                   AND/OR   
WDAYS                                                        WCAL           
MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y       
DATES                                                                       
CONFCAL          SHIFT       RETRO N MAXWAIT 06   D-CAT                     
MINIMUM PDS  
DEFINITION ACTIVE FROM UNTIL
  ============================================================================
  IN       SALARY-OK            ODAT                            
  CONTROL                                                                   
  RESOURCE                                                                  
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                   11.17.00

JOB: EBDRPT1A LIB CTM.PROD.SCHEDULE                             TABLE: EBDPROD
COMMAND ===>                                                    SCROLL===> CRSR
+-----------------------------------------------------------------------------+
  DESC    EBD PRODUCTION REPORTS                                            
  OVERLIB                                                   STAT CAL        
  SCHENV                         SYSTEM ID                  NJE NODE        
  SET VAR                                                                   
  CTB STEP AT         NAME            TYPE                                  
  DOCMEM  EBDRPT1A    DOCLIB   CTM.PROD.DOC                                 
  ===========================================================================
  SCHEDULE RBC                                                                
  RELATIONSHIP (AND/OR) O                                                     
  DAYS    01,15                                                 DCAL        
                                                                     AND/OR 
  WDAYS                                                         WCAL        
  MONTHS  1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y    
  DATES                                                                     
  CONFCAL          SHIFT       RETRO Y MAXWAIT 06  D-CAT                    
  MINIMUM          PDS                                                      
  DEFINITION ACTIVE FROM          UNTIL                                     
  ===========================================================================
  IN       SALARY-OK            ODAT      SALARY-OK            PREV
           IMS-ACTIVE           STAT                              
  CONTROL                                                                   
  RESOURCE                                                                  
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                    11.17.00

JOB: EBDUPDT2 LIB CTM.PROD.SCHEDULE                             TABLE: EBDPROD
COMMAND ===>                                                    SCROLL===> CRSR
+-----------------------------------------------------------------------------+
  APPL    EBD                         GROUP EBD-PRODUCTION                   
  DESC    EBD PRODUCTION UPDATE                                              
  OVERLIB                                                   STAT CAL         
  SCHENV                         SYSTEM ID                  NJE NODE         
  SET VAR                                                                    
  CTB STEP AT         NAME            TYPE                                   
  DOCMEM  EBDUPDT2    DOCLIB   CTM.PROD.DOC                                  
  ============================================================================
  DAYS                                                          DCAL         
                                                                     AND/OR  
  WDAYS   2,3,4,5,6                                             WCAL         
  MONTHS  1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y     
  DATES                                                                      
  CONFCAL          SHIFT       RETRO Y MAXWAIT 08  D-CAT                     
  MINIMUM          PDS                                                       
  DEFINITION ACTIVE FROM          UNTIL                                      
  ============================================================================
  IN       DEPOSITS             PREV                             
  CONTROL                                                                    
  RESOURCE                                                                   
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                    11.17.00

JOB: EBDRPT6C LIB CTM.PROD.SCHEDULE                             TABLE: EBDPROD
COMMAND ===>                                                    SCROLL===> CRSR
+-----------------------------------------------------------------------------+
  DESC    EBD PRODUCTION DATABASE REPORTS                                    
  OVERLIB                                                   STAT CAL         
  SCHENV                         SYSTEM ID                  NJE NODE         
  SET VAR                                                                    
  CTB STEP AT         NAME            TYPE                                   
  DOCMEM  EBDRPT6C    DOCLIB   CTM.PROD.DOC                                  
  ============================================================================
  DAYS    01,15                                                 DCAL         
                                                                     AND/OR  
  WDAYS                                                         WCAL         
  MONTHS  1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y     
  DATES                                                                      
  CONFCAL          SHIFT       RETRO Y MAXWAIT 04  D-CAT                     
  MINIMUM          PDS                                                       
  DEFINITION ACTIVE FROM          UNTIL                                      
  ============================================================================
  IN       |EBD-EBDUPDT2-ENDED  ODAT      |EBD-EBDUPDT3-ENDED  ODAT
           IMS-ACTIVE           STAT                               
  CONTROL                                                                    
  RESOURCE                                                                   
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                    11.17.00

JOB: EBDCLEAN LIB CTM.PROD.SCHEDULE                             TABLE: EBDPROD
COMMAND ===>                                                    SCROLL===> CRSR
+-----------------------------------------------------------------------------+
  OVERLIB CTM.OVER.JOBLIB                                   STAT CAL        
  SCHENV                         SYSTEM ID                  NJE NODE        
  SET VAR                                                                   
  CTB STEP AT         NAME            TYPE                                  
  DOCMEM  EBDCLEAN    DOCLIB                                                
  ============================================================================
  DAYS    ALL                                                   DCAL        
                                                                     AND/OR 
  WDAYS                                                         WCAL        
  MONTHS  1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y    
  DATES                                                                     
  CONFCAL          SHIFT       RETRO N MAXWAIT 00  D-CAT                    
  MINIMUM          PDS                                                      
  DEFINITION ACTIVE FROM          UNTIL                                     
  ============================================================================
  IN      (CICSP1-IS-UP        0101      |CICSP2-IS-UP)       0101         
          (OPR-CLEAN-REQUEST   ODAT      |SYS-CLEAN-REQUEST)  ODAT         
                                                                            
  CONTROL                                                                   
  RESOURCE INIT                 0001      CART                 0001         
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                    11.17.00

MEMNAME EBDRPT6D
MEMLIB  EBD.PROD.JOB
DAYS    01,15,20
MONTHS  1- N 2- N 3- N 4- N 5- N 6- N 7- Y 8- N 9- Y 10- N 11- N 12- N
IN      EBD-REPORTS-READY    ****

INSTREAM JCL: General Job Parameter

Whether Control-M for z/OS submits a JCL stream defined within the job scheduling definition, overriding the JCL in the member identified in the MEMLIB parameter and the OVERLIB parameter (if specified).

Figure 235 INSTREAM JCL Parameter Format

(Optional) Valid values for this parameter are:

• Y – Submit the defined JCL statements as the JCL for the job

• N – Use the JCL in the member identified in the MEMLIB parameter (default)

Under the INSTREAM JCL field is an empty line in which you can type a JCL statement. No JCL statement can contain more than 72 characters, including spaces. When you press Enter, a new line is opened in which another JCL statement can be typed.

You can enter up to 50 lines of JCL statements. The contents of these lines can be edited subsequently.

When the INSTREAM JCL parameter is set to Y, the library and member specified in the job definition are ignored.

General Information for INSTREAM JCL

Prior to version 6.2.00 of Control-M for z/OS, user-defined JCL that was to be run in the course of the execution of a job had to be defined in a JCL library.

The INSTREAM JCL parameter enables you to include JCL that is to be run in the course of the execution of a job within the definition of the job itself.

When the job is ordered or forced, any JCL defined using the INSTREAM JCL parameter resides in the Active Jobs file. The content of the JCL statements can then be modified by means of the Zoom and Save commands.

JCL that has been defined using the INSTREAM JCL parameter is processed by submit-related user exits, such as CTMX002, in the same way as JCL retrieved through the MEMLIB and MEMNAME parameters.

INTERVAL: Post–processing Parameter

Minimum time to wait between automatic reruns or cyclic runs of a job.

A related topic, cyclic jobs, is discussed in TASKTYPE: General Job Parameter.

Figure 236 INTERVAL Parameter Format

(Optional) INTERVAL consists of the subparameters described in Table 191.

Table 191 INTERVAL Subparameters

General Information for INTERVAL

The INTERVAL parameter defines a minimum interval between automatic reruns or cyclic runs of the same job.

Once the job has run, the Control-M Monitor does not rerun or resubmit the job unless both the following conditions are satisfied:

• the specified time has passed

• all runtime submission criteria, such as resources, conditions, and so on, are satisfied

The FROM subparameter specifies the point from which the interval is measured. The values set for this subparameter have the following effects:

• If STRT is specified, the interval is measured from the start time of the previous run.

• If END is specified, the interval is measured from the time the previous run ended.

• If TRGT is specified, the interval is measured from the scheduling time of the current job run.

  If no value was specified in the TIME FROM parameter, the interval is measured from the time the Control-M Monitor scheduled the current job run.

For more information about the TIME FROM parameter, see TIME + DAYS: Runtime Scheduling Parameter.

A job’s INTERVAL parameter is ignored when performing a Rerun (R) command for a job in screen 3.

Example for INTERVAL

JOB: ADBBKPS  LIB  CTM.PROD.SCHEDULE                            TABLE: ADABAS
COMMAND ===>                                                    SCROLL===> CRSR
 +---------------------------------------------------------------------------+
  ===========================================================================
  OUT                                                                       
  AUTO-ARCHIVE Y           SYSDB    Y      MAXDAYS      MAXRUNS             
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP               
  SYSOUT OP   (C,D,F,N,R)                                               FROM
  MAXRERUN 9    RERUNMEM                        INTERVAL 0015 M FROM END
  STEP RANGE         FR (PGM.PROC)          .          TO           .       
  ON PGMST BACKUP   PROCST          CODES U0034                         A/O 
    DO RERUN                                                                
    DO                                                                      
  ON PGMST          PROCST          CODES                               A/O 
    DO                                                                      
  ON SYSOUT                                          FROM 001 TO 132    A/O  
    DO                                                                
  ON VAR                                                              
    DO                                                                
  SHOUT WHEN           TIME       +     DAYS     TO                  URGN   
    MS                                                                      
===== >>>>>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<<< =====
                                                                            
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                    11.17.00

INTERVAL SEQUENCE: Runtime Scheduling Parameter

The job runs are separated according to the specified sequence of intervals. This field exists in both the Job Scheduling and SMART Table Entity Definition Screens.

(Optional) INTERVAL SEQUENCE consists of the subparameters described in Table 192.

Table 192 INTERVAL SEQUENCE Subparameters

General Information for INTERVAL SEQUENCE

The INTERVAL SEQUENCE parameter defines an interval sequence between reruns or cyclic runs of the same job.

Once the job has run, the Control-M Monitor does not rerun or resubmit the job unless both the following conditions are satisfied:

• the defined interval of time for the next rerun has passed

• all runtime submission criteria, such as resources, conditions, and so on, are satisfied

The FROM subparameter specifies the point from which the interval is measured. The values set for this subparameter have the following effects:

• When the value of FROM is STRT, the time until the next job run is counted from the moment that the current job run begins.

• When the value of FROM is END, the time until the next job run is counted from the moment that the current job run is complete.

A Rerun command (R) can be performed only after all planned intervals have been completed.

The figure below shows an example of the INTERVAL SEQUENCE parameter.

Figure 238 INTERVAL SEQUENCE Parameter Example

JOB: ADBBKPS  LIB  CTM.PROD.SCHEDULE                            TABLE: ADABAS
COMMAND ===>                                                    SCROLL===> CRSR
 +---------------------------------------------------------------------------+
  ===========================================================================
  OUT                                                                       
  AUTO-ARCHIVE Y           SYSDB    Y      MAXDAYS      MAXRUNS             
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP               
  SYSOUT OP   (C,D,F,N,R)                                               FROM
  MAXRERUN 9    RERUNMEM                                                    
  CYCLIC TYPE: V                                    INTERVAL          FROM  
  INTERVAL SEQUENCE:  + 00030 M + 00004 H + 00007 D +            +          
                      +         +         +         +            +          
  SPECIFIC TIMES:                                               TOLERANCE   
                         +           +          +          +           +    
                                                                            
                                                                            

KEEP AT LEAST ## DAYS AFTER ENDED NOT OK: Post-Processing Parameter

Determines the minimum number of days the SMART Table is kept in the AJF after its first job failure, when the table is marked as "NOT-OK". The days are counted from the completion of the first day where a job in the table ended NOT OK. The user can set enough time to properly investigate all the jobs in the SMART Table, including the jobs that ended OK.

Figure 239 KEEP AT LEAST ## DAYS AFTER ENDED NOT OK Parameter Format

  DESC
  ADJUST CONDITIONS               TBL MAXWAIT      STAT CAL                 
  KEEP JOBS UNTIL REMOVED         KEEP AT LEAST    DAYS AFTER ENDED NOT OK  
  SET VAR                                                                   

(Optional) Valid values include any number in the range from 0-99.

Table 193 KEEP AT LEAST ## DAYS AFTER ENDED NOT OK Parameter Values

KEEP JOBS UNTIL REMOVED: Post-Processing Parameter

Determines that all the jobs in the SMART Table will be kept in the Active Jobs File until the SMART Table is removed from the AJF.

Figure 240 KEEP JOBS UNTIL REMOVED Parameter Format

  DESC
  ADJUST CONDITIONS               TBL MAXWAIT      STAT CAL                 
  KEEP JOBS UNTIL REMOVED    KEEP AT LEAST    DAYS AFTER ENDED NOT OK  
  SET VAR

(Optional) Valid values are indicated in the following table.

Table 194 KEEP JOBS UNTIL REMOVED Parameter Values

Setting KEEP JOBS UNTIL REMOVED to Y allows the user to examine the entire SMART Table, including the jobs that completed OK on preceding days, until the SMART Table completes OK.

MAXRERUN: Post–processing Parameter

Maximum number of automatic reruns to be performed for the job. This field exists in both the Job Scheduling and SMART Table Entity Definition Screens. Called RERUN – MAXRERUN prior to version 6.0.00.

Figure 241 MAXRERUN Parameter Format

(Optional) For non-cyclic jobs, valid values are blank or 0 through 255. For cyclic jobs, valid values are blank or 0 through 9999. Default: blank (for non-cyclic jobs - no automatic reruns; for cyclic jobs - unlimited cyclic iterations).

General Information for MAXRERUN

When a job is first run, the MAXRERUN field in the Active environment, that is, in the Zoom screen, contains the same value as the MAXRERUN parameter in the job scheduling definition. However, in the Active environment MAXRERUN works as a "reverse-counter" of automatic reruns. Each time the job is automatically rerun, the value is decreased by one until the field contains a value of zero.

The automatic rerun process works as follows:

1. The Control-M monitor determines that automatic rerun is possible only if the job ENDS NOTOK and a specified DO RERUN statement is activated during post-processing. If the monitor determines that automatic rerun is possible, it sets the status of the job to ENDED NOTOK – RERUN NEEDED.

2. The monitor then checks the value of MAXRERUN in the Active environment. If the value is zero, automatic rerun is not possible and the job is not submitted for rerun. If the value is greater than zero, rerun is possible and the monitor submits the job for rerun when all runtime criteria are satisfied. Runtime criteria include not only criteria in the Runtime Scheduling parameters, but also the INTERVAL parameter, which specifies the minimum allowable interval between runs of the same job.

3. The JCL for the rerun job is taken from the member specified in the RERUNMEM parameter. If no RERUNMEM value is specified, the JCL for the rerun is taken from the regular JCL member of the job that is specified in the MEMNAME parameter.

MAXRERUN applies only to automatic reruns. The MAXRERUN counter is not affected by reruns performed manually using the Rerun option in the Active Environment screen.

If a job is defined as cyclic by setting the TASKTYPE parameter to CYC, the MAXRERUN parameter can be used to specify the number of iterations. This number includes the initial run of the job.

Examples for MAXRERUN

MAXRERUN  2  RERUNMEM                   INTERVAL 0015  M     FROM END
ON PGMST STEP01   PROCST          CODES S613
  DO RERUN

JOB: PRDKPL01 LIB   CTM.PROD.SCHEDULE                          TABLE: PRODKPL
COMMAND ===>                                                   SCROLL===> CRSR
 +---------------------------------------------------------------------------+
  ===========================================================================
  OUT      PRDKPL01-ENDED-OK           ODAT +                               
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS              
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP               
  SYSOUT OP   (C,D,F,N,R)                                               FROM
  MAXRERUN  2  RERUNMEM                             INTERVAL 0015 M FROM END
  STEP RANGE           FR (PGM.PROC)          .        TO          .        
  ON PGMST ANYSTEP    PROCST        CODES S***   U****  C2000           A/O 
  DO IFRERUN   FROM $ABEND   .          TO          .                CONFIRM N
    DO RERUN                                                                
    DO                                                                      
  ON PGMST            PROCST        CODES                               A/O 
    DO                                                                      
  ON SYSOUT                                          FROM 001 TO 132    A/O  
    DO                                                                
  ON VAR                                                              
    DO                                                                
  SHOUT WHEN           TIME       +     DAYS     TO                  URGN   
     MS                                                                     
 ======= >>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<<< ======
                                                                            
                                                                            
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                    11.17.00

MAXWAIT: Basic Scheduling Parameter

Number of extra days the job can wait in the Active Jobs file for submission.

Figure 243 MAXWAIT Parameter Format

(Optional) Valid Values: any 2-digit number in the range from 00 through 98, or 99.

Table 195 MAXWAIT Parameter Values

If no value is specified, the default value of 00 is automatically inserted. This default value may be changed by your INCONTROL administrator, by means of Wish WM2367 in the IOADFLT member in the IOA IOAENV library (by setting a 2-digit number in the DATAC parameter).

General Information for MAXWAIT

The MAXWAIT parameter is used to overcome the problem of delays in production. A job that is scheduled for execution on a specific day does not always get executed that same day. This can be due to a number of reasons, such as hardware failure or a heavy production workload. Therefore, it may be desirable to specify an additional number of days that the job must remain in the Active Jobs file awaiting execution.

When a job cannot be submitted for execution within the specified time limits, an appropriate message is written to the IOA Log file, and the job is deleted from the Active Jobs file.

Jobs scheduled as a result of a Y value in the RETRO parameter are always given at least one day within which to execute, even if the MAXWAIT parameter indicates that they must no longer be in the Active Jobs file. This occurs when the current working date exceeds the original scheduling date (ODATE) by more than the number of days specified in the MAXWAIT parameter on the day the job is scheduled by RETRO=Y. For more information, see RETRO: Basic Scheduling Parameter.

Emergency jobs not belonging to a group (parameter) are discarded if their specified MAXWAIT periods have passed. An emergency job that belongs to a specific group (specified in the GROUP parameter) and whose MAXWAIT period has not passed is not deleted from the Active Jobs file until all of the regular jobs that belong to the same group have finished executing. This is in case the job is needed at a later stage.

When a job is not ENDED OK, the MAXWAIT of a job is affected by the FROM DAYS and UNTIL DAYS parameters. The job remains in the AJF until the end of the logical UNTIL DAY. The job is only deleted from the AJF on MAXWAIT days after the job's ODATE (provide that the Control-M logical date is later than the job's ODATE plus MAXWAIT).

For jobs containing a time zone later than the local Control-M time, one day is added to MAXWAIT so that the job will stay one additional day on the Active Jobs file.

For ON SPOOL jobs in WAIT SCHEDULE status, the MAXWAIT parameter is ignored. Jobs in this status are not removed from the AJF even after the MAXWAIT value is exceeded, but remain in the AJF until their status is changed to ENDED OK or ENDED NOTOK.

MAXWAIT Values for Jobs in a SMART Table

The MAXWAIT value for jobs in a SMART Table is normally determined by the MAXWAIT parameter in rule-based calendars defined in the SMART Table Entity. However:

• If the RBCMAXWT parameter in the CTMPARM member in the IOA PARM library is set to N (No), the MAXWAIT value for each job in the SMART Table is instead determined by the value of the MAXWAIT parameter in its job scheduling definition.

• If AND is specified in the RELATIONSHIP parameter, the MAXWAIT value from the job scheduling definition is used (regardless of the value of the RBCMAXWT parameter).

• If a job in a SMART Table is forced, the MAXWAIT value is determined by the value of the MAXWAIT parameter in the job scheduling definition, regardless of the value of the RBCMAXWT parameter.

MAXWAIT Values for Cyclic Jobs

If a cyclic job is executing at the time the New Day procedure is run and the job's MAXWAIT value is reached, the New Day procedure changes the job to a non-cyclic job so that it can subsequently be deleted during the next New Day procedure.

Examples for MAXWAIT

JOB: OPERJOB  LIB CTM.PROD.SCHEDULE                            TABLE: OPER
COMMAND ===>                                               SCROLL===> CRSR
+------------------------------------------------------------------------+
  MEMNAME OPERJOB      MEMLIB  CTM.PROD.JCL                               
  OWNER   SYS1         TASKTYPE JOB    PREVENT-NCT2 Y   DFLT  N           
  APPL    OPER                         GROUP MAINTENANCE                  
  DESC    JOB RUN IN FIRST HALF OF THE MONTH                              
  OVERLIB                                                   STAT CAL      
  SCHENV                         SYSTEM ID                  NJE NODE      
  SET VAR                                                                 
  CTB STEP AT         NAME            TYPE                                
  DOCMEM  OPERJOB     DOCLIB   CTM.PROD.DOC                               
  ========================================================================
  DAYS    02,04,06                                              DCAL      
                                                                    AND/OR
  WDAYS                                                         WCAL      
  MONTHS  1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y  
  DATES                                                                   
  CONFCAL          SHIFT       RETRO Y MAXWAIT 03  D-CAT               
  MINIMUM          PDS                                                    
  DEFINITION ACTIVE FROM          UNTIL                                   
  ========================================================================
  IN                                                                      
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                               11.17.00

MAXWAIT 99

 JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE                       TABLE: PRODKPL 
 COMMAND ===>                                             SCROLL===> CRSR
 +----------------------------------------------------------------------+
   MEMNAME PRDKPL01    MEMLIB   CTM.PROD.JCL                             
   OWNER   SYS1        TASKTYPE JOB    PREVENT-NCT2   DFLT  N            
   APPL    KPL                         GROUP PROD-KPL                    
   DESC    DAILY PRODUCTION - START OF APPL-PROD-KPL                     
   OVERLIB                                                   STAT CAL    
   SCHENV                         SYSTEM ID                  NJE NODE    
   SET VAR                                                               
   CTB STEP AT         NAME            TYPE                              
   DOCMEM  PRDKPL01    DOCLIB   CTM.PROD.DOC                             
   ======================================================================
   DAYS                                                     DCAL WORKDAYS
                                                                   AND/OR
   WDAYS                                                      WCAL       
   MONTHS  1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
   DATES                                                                 
   CONFCAL          SHIFT       RETRO Y MAXWAIT 01  D-CAT                
   MINIMUM          PDS                                                  
   DEFINITION ACTIVE FROM          UNTIL                                 
   ======================================================================
   IN                                                                    
  COMMANDS: EDIT, DOC, PLAN, JOBSTAT                             11.17.00

MAXWAIT 00

MEMLIB: General Job Parameter

For a job (or warning messages): Name of the library containing the member specified in the TABLE parameter.

For a started task: Required started task information.

A related parameter is discussed in OVERLIB: General Job Parameter.

Figure 246 MEMLIB Parameter Format

Mandatory. Format of the parameter depends on whether the job scheduling definition applies to a job (or warning messages) or a started task:

• For a job (or warning messages):

  Valid values are a valid data set name of 1 through 44 characters, or one of the reserved values shown in Table196.

  Table 196 MEMLIB Parameter Values for Non-Started Tasks

  Value	Description
  DUMMY	For dummy jobs. For warning messages, do not use DUMMY as a value for this parameter.
  USER=name	For user-defined libraries.
  GENERAL	Specifies the library referenced by the DALIB DD statement in the Control-M procedure.
  DDNAME=ddname	Specifies the library/member pointed to by the ddname DD statement in the Control-M monitor procedure from which the JCL is to be submitted.

• For a started task:

  Any of the formats shown in Table 197 can be used for the MEMLIB value.

  Table 197 MEMLIB Parameter Formats for Started Tasks

  Format	Description
  *.taskid	Where taskid is the task ID. The STC is activated in the computer in which the Control-M monitor is active.
  cpuid, stcparms	Where cpuid is the ID of the computer in which the STC is to be activated (see the following value "cpuid"); stcparms represents STC parameters.
  cpuid.taskid	Where cpuid is the ID of the computer in which the STC is to be activated (see the following value "cpuid"); taskid is the identifier to be specified on the start command.
  cpuid	Where cpuid is the ID of the computer in which the STC is to be activated. Valid cpuid values are: * – The same computer where the Control-M monitor is active. Under JES2: Nn – Where n is the JES/NJE node ID. Mm – Where m is the machine ID.    NnMm – Where n is the JES/NJE node ID, and m is the machine ID. When using the cpuid,stcparms format (see above), any quotes specified in the stcparms must be doubled. Under JES3: Lname – Where name is the logical JES name of the machine, that is, the name as used in the JES3 command *T, not the SMF system ID.

General Information for MEMLIB

Whether the job scheduling definition applies to a job, warning messages, or a started task is determined by the values defined in the TASKTYPE parameter, which is described in TASKTYPE: General Job Parameter.

AutoEdit variables can be specified and are resolved. Even the machine ID, which is relevant for started task initiation, can be automatically replaced based on resource allocation. For more information, see JCL and AutoEdit Facility.

For Jobs (or Warning Messages)

The library can be any standard cataloged partitioned data set (PDS or PDSE), LIBRARIAN or PANVALET. The record length must be 80.

The library and the member do not have to exist when the job production parameters are defined. Their existence is checked by Control-M before actual submission of the job.

If, during the access to a library by Control-M (before submission), the library is held exclusively by another user, such as a TSO user or job, the monitor tries to access the library every few seconds until the library is released and the job can be submitted. If the library is migrated, for example, through HSM, Control-M remains in a WAIT state until the library is recalled.

Use of the library name DUMMY is intended for scheduling events, for example, adding a prerequisite condition without actually running the job. If the library name DUMMY is used, the job is not submitted; submission and sysout checking are skipped. In this case, the job is assumed to have ended OK (ON PGMST...DO processing is not performed), and Post-Processing parameters associated with an ENDED OK status are activated (OUT, SHOUT WHEN OK).

If the library name is GENERAL:

• The job is submitted from the library referenced by the DALIB DDstatement of the Control-M procedure. This library must be a partitioned data set or a concatenation of partitioned data sets.

• The standard ISPF Editor cannot process more than four concatenated libraries. The editor saves the edited member in the first library in the concatenation.

  Control-M Exit CTMX014 (the CTMX014G member in the IOA SAMPEXIT library) enables you to bypass these limitations if the members are going to be edited online through the J(JCL) option in the Job List screen or the Active Environment screen.

• The prefix USER= must be specified when a special type of user library is used. When using this prefix, the member is not read by Control-M using the normal mechanism. Instead Control-M submission Exit CTMX002 must be coded to handle access and submission of the library and member. In such cases, the Control-M monitor ignores the data specified in the MEMLIB/MEMNAME parameters; however, the substring following the USER= may be used by the exit. For examples of the exit, see the IOA SAMPEXIT library.

When specifying option J (JCL) in the Job List screen or the Active Environment screen in order to edit the JCL member, Control-M must determine which library (MEMLIB or OVERLIB) to use.

For Started Tasks

A started task is activated in the specified computer ID. This is the ID of the computer in JES, not the 4-character SMF ID. You can use the $D MEMBER JES command to determine the JES ID. For more information, see the discussion on specifying IOA CPUs in the description of the customization process in the INCONTROL for z/OS Installation Guide. If the computer ID is followed by a comma and parameters, the parameters are applied to the started task.

Examples for MEMLIB

MEMNAME IMSBKUP
MEMLIB  SYS2.IMS.JOB

MEMNAME COLCTSMF
MEMLIB  *,DATE=%%ODATE

S COLCTSMF,DATE=000905

MEMNAME GTF
MEMLIB  *.G01

S GTF.G01

MEMNAME COLCTSMF
MEMLIB  N1,DATE=%%ODATE

MEMNAME COLCTSMF
MEMLIB  N1M1,DATE=%%ODATE

MEMNAME STAMSTC
MEMLIB  M2.IDNTFIER

$M2,'S STAMSTC.IDNTFIER'

MEMNAME: General Job Parameter

Name of the member that contains one of the following (depending on the defined task type):

• JCL of the job

• Started task procedure

• Warning messages

For more information, see MEMLIB: General Job Parameter.

Figure 247 MEMNAME Parameter Format

Mandatory. MEMNAME identifies a valid member name of 1 through 8 characters. For On Spool jobs, mask characters * and ? are supported. For details, see Character Masking and On Spool Jobs.

AutoEdit variables are supported.

General Information for MEMNAME

The MEMNAME parameter identifies a member whose contents are determined by the task type of the job scheduling definition. For more information, see TASKTYPE: General Job Parameter.

• If TASKTYPE contains the value JOB, CYC, EMR or ECJ, the job scheduling definition is defined for a job and the MEMNAME parameter identifies the member that contains the JCL of the job.

• If TASKTYPE contains the value STC, CST, EST or ECS, the job scheduling definition is defined for a started task and the MEMNAME parameter identifies the member that contains the started task procedure.

• If TASKTYPE contains the value WRN, the job scheduling definition is defined for warning messages and the MEMNAME parameter identifies the member that contains the warning messages.

The member name may be the same as or different than the job name.

The member can contain the JCL of more than one job. By default, Control-M processes only the first job in the member. If, however, the MULTJOBS parameter in the CTMPARM member in the IOA PARM library is set to Y (Yes), Control-M submits all the jobs in the member, but still only monitors the execution and results of the first job in the member. Therefore, BMC recommends that each member contain the JCL of only one job.

Example for MEMNAME

 JOB: OPERCOMP LIB CTM.PROD.SCHEDULE                            TABLE: OPER
 COMMAND ===>                                                   SCROLL===> CRSR
 +----------------------------------------------------------------------------+
   TABLE OPERCOMP    MEMLIB   CTM.PROD.JCL                             
   OWNER   SYS1        TASKTYPE JOB    PREVENT-NCT2   DFLT  N              
   APPL    OPER                        GROUP MAINTENANCE                   
   DESC    JOB RUN ON THE 1ST OF THE MONTH                                 
   OVERLIB                                                   STAT CAL      
   SCHENV                         SYSTEM ID                  NJE NODE      
   SET VAR                                                                 
   CTB STEP AT         NAME            TYPE                                
   DOCMEM  OPERCOMP    DOCLIB   CTM.PROD.DOC                               
   ==========================================================================
   DAYS    01                                                    DCAL      
                                                                      AND/OR
   WDAYS                                                         WCAL      
   MONTHS  1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y  
   DATES                                                                   
   CONFCAL          SHIFT           RETRO Y MAXWAIT 00  D-CAT              
   MINIMUM          PDS                                                    
   DEFINITION ACTIVE FROM          UNTIL                                   
   ==========================================================================
   IN                                                                      
  COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                   11.17.00

MINIMUM: Basic Scheduling Parameter

Minimum number of free tracks required by the library specified in the PDS parameter.

A related parameter is discussed in PDS: Basic Scheduling Parameter.

Figure 249 MINIMUM Parameter Format

(Optional) However, if PDS is specified, MINIMUM is mandatory. The MINIMUM parameter specifies the minimum number of free tracks required. This must be a positive 3-digit number; leading zeros are inserted if necessary.

The MINIMUM parameter cannot be used with the DAYS, WDAYS, MONTHS, CONFCAL, RETRO and DATES parameters.

General Information for MINIMUM

The MINIMUM and PDS parameters are always used together and are never used with other Basic Scheduling parameters.

The PDS parameter identifies a library, and the MINIMUM parameter specifies the minimum number of free tracks required by that library.

These parameters are intended for use (that is, definition) in jobs and started tasks that compress, clean and/or enlarge libraries, or which issue a warning message to the IOA Log file (that is, if TASKTYPE=WRN) if the minimum number of free tracks is not available.

If the MINIMUM and PDS parameters are defined for a job, the scheduling of the job is not related to or dependent upon any date criteria. Instead, the job is scheduled if the actual number of free tracks available in the specified library is below the specified minimum at time of daily job ordering. The job or started task can then compress, clean, or enlarge the library (or issue the appropriate warning).

Examples for MINIMUM

 JOB: OPERCOMP LIB CTM.PROD.SCHEDULE                            TABLE: OPER
 COMMAND ===>                                                   SCROLL===> CRSR
 +----------------------------------------------------------------------------+
   MEMNAME OPERCOMP    MEMLIB   GENERAL                                    
   OWNER   SYS1        TASKTYPE JOB    PREVENT-NCT2   DFLT  N              
   APPL    OPER                        GROUP OPER-MAINT                    
   DESC    COMPRESS OF ALL.PARMLIB                                         
   OVERLIB                                                   STAT CAL      
   SCHENV                         SYSTEM ID                  NJE NODE      
   SET VAR                                                                 
   CTB STEP AT         NAME            TYPE                                
   DOCMEM  OPERCOMP    DOCLIB   CTM.PROD.DOC                               
   ==========================================================================
   DAYS                                                          DCAL      
                                                                      AND/OR
   WDAYS                                                         WCAL      
   MONTHS  1-   2-   3-   4-   5-   6-   7-   8-   9-   10-   11-   12-    
   DATES                                                                   
   CONFCAL          SHIFT       RETRO Y MAXWAIT 00  D-CAT                  
   MINIMUM 020      PDS   ALL.PARMLIB                                
   DEFINITION ACTIVE FROM          UNTIL                                   
   ==========================================================================
   IN                                                                      
  COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                   11.17.00

MEMNAME  MSG001
TASKTYPE WRN
PDS      USER.LIBRARY
MINIMUM  050

MONTHS: Basic Scheduling Parameter

Months of the year in which the job must be scheduled.

Figure 252 MONTHS Parameter Format

(Optional) The months in the year are represented by the numbers 1 through 12. A value can be specified for each month.

Valid Values:

Table 198 MONTHS Parameter Values

General Information for MONTHS

In general, the job is scheduled for execution only during the months in which a value of Y is specified and only if the job would have also been scheduled due to some other basic scheduling parameter (such as DAYS, WDAYS, and so on); that is, the MONTHS parameter serves as a limiting filter. There are certain exceptions that are noted below.

The MONTHS parameter cannot be used with the PDS and MINIMUM parameters.

If values are set for both the MONTHS parameter and the DATES parameter, the MONTHS parameter setting is ignored.

A job can be scheduled in a month not specified as a working month if a greater than or less than qualifier in the DAYS specification shifts the scheduling out of the current month, and the month to which it shifts is a non-scheduled month, the job is nevertheless scheduled in that non-scheduled month.

For example, if the values of the DAYS parameter >31, the MONTHS parameter indicates JANUARY and MARCH (but not FEBRUARY). The associated calendar has all days except JANUARY 31 as working days. Then the job is scheduled on February 1.

Examples for MONTHS

MONTHS  1- N 2- N 3- Y 4- N 5- N 6- N 7- N 8- N 9- Y 10- N 11- N 12- N

 JOB: OPERCOMP LIB CTM.PROD.SCHEDULE                             TABLE: OPER
 COMMAND ===>                                                    SCROLL===> CRSR
 +----------------------------------------------------------------------------+
   MEMNAME OPERCOMP    MEMLIB   CTM.PROD.JCL                                
   OWNER   SYS1        TASKTYPE JOB    PREVENT-NCT2   DFLT  N               
   APPL    OPER                        GROUP MAINTENANCE                    
   DESC    JOB RUN ON THE 1ST OF THE MONTH                                  
   OVERLIB                                                   STAT CAL       
   SCHENV                         SYSTEM ID                  NJE NODE       
   SET VAR                                                                  
   CTB STEP AT         NAME            TYPE                                 
   DOCMEM  OPERCOMP    DOCLIB   CTM.PROD.DOC                                
   ==========================================================================
   DAYS    01                                                    DCAL       
                                                                      AND/OR
   WDAYS                                                         WCAL       
   MONTHS  1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y  
   DATES                                                                    
   CONFCAL          SHIFT       RETRO Y MAXWAIT 00  D-CAT                   
   MINIMUM          PDS                                                     
   DEFINITION ACTIVE FROM          UNTIL                                    
   ==========================================================================
   IN                                                                       
  COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                   11.17.00

NJE NODE: General Job Parameter

Identifies the node in the JES network at which the job is to execute.

Figure 254 NJE NODE Parameter Format

NJE NODE specifies a node name of 1 through 8 characters. Only trailing blanks are allowed.

By default, the NJE NODE parameter is optional.

General Information for NJE NODE

The NJE NODE parameter is used to identify the node in the JES network at which the job is to execute.

If a value is specified for the NJE NODE parameter, a JCL statement is generated. The precise form of the statement depends on whether Control-M is running under JES2 or JES3.

If the task type is a started task, NJE NODE is protected. If the task type is changed from a job to a started task, NJE NODE is erased and protected.

Under JES2

If Control-M is running under JES2, the NJE NODE parameter generates the following JCL statement:

/*ROUTE XEQ node_name

Under JES3

If Control-M is running under JES3, the JCL statement generated by the NJE NODE parameter differs slightly, taking the following form:

//*ROUTE XEQ node_name

Note that if a JES3 NJB job statement is not present in the job, the //*ROUTE XEQ JCL statement is not generated.

If a value is specified for the NJE NODE parameter, it will not override any node name specified in the job statement unless the OVERJCLM parameter in the CTMPARM library is set to Y.

Examples for NJE NODE

DESC
OVERLIB                                                STAT CAL
SCHENV                      SYSTEM ID                  NJE NODE  OS35   

/*ROUTE XEQ OS35

DESC
OVERLIB                                                STAT CAL       
SCHENV                      SYSTEM ID                  NJE NODE  OS35 

//*ROUTE XEQ OS35

ON Statements: Post–processing Parameter

Job processing criteria that determine whether the accompanying DO statements are performed.

Figure 255 ON Statement Format Example

ON statements identify specific steps in the execution of a Control-M job or group.

The types of ON statement are described in Table 199. Each type is discussed in detail in this chapter.

Table 199 ON Statement Types

General Information for ON Statements

ON statements are usually, but not necessarily, followed by user-specified DO actions. The implied relationship between ON statements and associated DO statements is: if ON statement criteria are satisfied, perform the associated DO statement actions.

The combination of ON statements and DO statements enables you to specify post-processing actions that depend on execution results.

In a new job or table scheduling definition, an empty ON statement is followed by an empty DO statement. Additional ON statements can be opened in the job scheduling definition, as required.

Multiple ON statements of various types can be specified. In addition, multiple ON statements of the same type (not including ON TABLE-END) can be linked together by Boolean logic in an an ON block.

ON TABLE-END: Post–processing Parameter

Table processing criteria that determine whether the accompanying DO statements are performed. Found in SMART Table Entities only.

Figure 256 ON TABLE-END Parameter Format

(Optional) Valid values are shown in Figure 201.

Table 200 ON TABLE-END Values

General Information for ON TABLE-END

The ON TABLE-END parameter enables specification of DO statements to be performed when the processing of the group ends with the indicated status.

By default, if not all jobs in the group ended OK, the DO statements accompanying an ON TABLE-END NOTOK parameter are performed. This applies if at least one job ended NOTOK, and it can also apply if a job in the group was deleted and all remaining jobs in the group ended OK. However, if the TBLDELJB parameter in the CTMPARM member in the IOA PARM library is set to O (OK), deleted jobs are not considered, and status END NOTOK applies only if at least one job ended NOTOK.

If the job that ended NOTOK is subsequently successfully rerun, so that the termination status of the SMART Table changes to OK, the DO statements accompanying an ON TABLE-END OK parameter are then performed.

The SMART Table failure counter (used for checking FCnnn condition) is increased by one each time the SMART Table status is changed from Active to Ended NOTOK.

The following DO statements can be specified following an ON TABLE-END statement:

• DO COND

• DO FORCEJOB

• DO NOTOK

• DO OK

• DO SET

• DO SHOUT

• DO MAIL

• DO REMEDY

• DO REMFORCE

DO OK or DO NOTOK statements change the final status of the group, not the status of each job or job step in the table.

Use of the ON TABLE-END parameter in the SMART Table Entity can frequently reduce the number of individual DO statements that would otherwise require definition in individual job scheduling definitions.

For example, suppose that following the processing of the group, you want to force a particular job if any of the jobs in the group ENDED NOTOK.

• This result can be achieved by defining an ON TABLE-END NOTOK DO statement (in the SMART Table Entity) followed by the appropriate DO FORCEJOB statement.

• To achieve this result without use of the ON TABLE-END parameter, the following steps would be necessary:

  • In each job scheduling definition in the table, define an appropriate condition that would be added to the IOA Conditions file when the job ends NOTOK.

  • In the table, define an additional job to be performed after the other jobs in the table have terminated. This job would have as an IN condition the condition added by the jobs that ended NOTOK, and would trigger the appropriate job.

Multiple ON TABLE END Statements and ON TABLE END Blocks

Multiple ON TABLE-END parameters can be defined. Upon specifying an ON TABLE-END value and pressing Enter, a new ON TABLE-END statement, followed by a blank DO statement, is opened.

Example for ON TABLE-END

TBL ACCOUNTS_GROUP       CTM.PROD.SCHEDULE(TBL)
COMMAND ===>                                                    SCROLL===> CRSR
+-----------------------------------------------------------------------------+
  ===========================================================================
  SCHEDULE RBC                                                               
  DAYS                                                          DCAL         
                                                                     AND/OR  
  WDAYS                                                         WCAL         
  MONTHS  1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y     
  DATES                                                                      
  CONFCAL          SHIFT       RETRO N MAXWAIT 00                            
  SCHEDULE RBC ACTIVE FROM          UNTIL                                    
  ===========================================================================
  IN                                                                         
  CONTROL                                                                    
  FROM TIME         +     DAYS    UNTIL TIME      +     DAYS  
  DUE OUT TIME      +     DAYS    PRIORITY     SAC    CONFIRM 
  TIME ZONE:                                                                 
  ===========================================================================
  OUT                                                                        
  ON TABLE-END NOTOK                                             
    DO COND          ACCTS-CHK-REQUIRED   ODAT +                 
  ON VAR                                                  
    DO                         
  SHOUT WHEN           TIME       +     DAYS     TO                  URGN   
    MS                                                                       
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                    18.19.14

Confirmation Panel for ON TABLE-END

If the DFJCONF profile variable is set to Y, and the JOB parameter in the DO FORCEJOB request is blank, a confirmation panel is displayed when exiting the Job Scheduling Definition screen. The confirmation panel is displayed only once for each DO FORCEJOB statement.

Figure 258 ON TABLE-END Confirmation Panel

+----------------------------------------------------------+
|                                                          |
|  THIS JOB CONTAINS ONE OR MORE DO FORCEJOB STATEMENTS.   |
|  WHEN THE JOB IS ORDERED:                                |
|  ARE YOU SURE YOU WANT TO FORCE THE WHOLE TABLE IN THE   |
|  FORCEJOB STATEMENT(S)?    (Y/N)                         |
|                                                          |
+----------------------------------------------------------+

Enter Y to save the table and return to the Job List screen, or N to return to the table without saving it.

ON PGMST: Post–processing Parameter

Job processing step and code event criteria that determine whether the accompanying DO statements are performed.

For more information, see Step Name: +EVERY.

Figure 259 ON PGMST Parameter Format

(Optional) ON PGMST statements define event criteria that identify specific Control-M job steps and possible codes that result from the execution of those job steps.

The ON PGMST statement consists of the subparameters described in Table 201. When used, at least one step and one code must be specified.

Table 201 ON PGMST Subparameters

General Information for ON PGMST

ON PGMST statements are usually, but not necessarily, followed by user-specified DO actions. The implied relationship between ON PGMST statements and associated DO statements is described in ON Statements: Post–processing Parameter.

Multiple ON PGMST Statements and ON PGMST Blocks

In a new job scheduling definition, an empty ON PGMST statement is followed by an empty DO statement. Additional ON PGMST statements can be opened in the job scheduling definition as follows:

• When you set values for ON PGMST, PROCST, and CODE, and press Enter, an empty ON PGMST and DOstatement is opened following the current ON PGMST and DO statements. The new ON PGMST and DO statements, if filled in, are not logically connected to the preceding ON PGMST and DOstatements. They constitute a new ON PGMST block and DO block.

  Multiple ON PGMST blocks are generally interpreted sequentially from first to last, except when an ON PGMST block contains an And/Or Boolean connector. All such blocks containing Boolean connectors are processed last regardless of their position in the list of ON PGMST blocks.

  If the conditions of an ON PGMST block are satisfied, the accompanying DO actions are performed. The conditions of more than one ON PGMST block can be satisfied; therefore, more than one set of DO statements can be performed.

  One ON PGMST block specifies STEP1 as the program step, and >C0004 as the CODE.

  A second ON PGMST block specifies ANYSTEP as the program step, and >C0008 as the CODE.

  If STEP1 results in a condition code of C0016, the ON PGMST step and CODE event criteria for both ON PGMST statements are satisfied, and the DO actions accompanying both ON PGMST blocks are performed.

• When you fill in the A/O (And/Or) subparameter of an ON PGMST statement, an empty ON PGMST statement is opened immediately, that is, before the accompanying DO statement. The specified A/O value logically connects the new ON PGMST statement to the preceding ON PGMST statement. These two ON PGMST statements constitute a single ON PGMST block.

  Copy

  ON PGMST STEP1 ... CODES C0004 ... A/O A
  ON PGMST STEP5 ... CODES S0C4 ...  A/O
  DO SHOUT ...

  In the above ON PGMST and DO statements, for the DO SHOUT action to be performed, STEP1 must end with a condition code of C0004, and STEP5 must end with an S0C4 system abend.

To add an empty ON PGMST statement between two existing ON PGMST statements, type the > character over the first letter in the ON PGMST value of the previous ON PGMST line, and press Enter.

ON PGMST >TEP1

To delete unwanted ON PGMST statements, specify appropriate Line Editing commands in the Edit environment. For information on the Edit environment, see Editing Job Scheduling Definitions in the Edit Environment, and in particular Line Editing Commands.

Job/Step Completion Status Facility (JSCSF)

General ON PGMST definitions can be created using the Job/Step Completion Status Facility (JSCSF) and may override the in-job definitions. For more information, see the "The Job/Step Completion Status Facility (JSCSF)" section in the INCONTROL for z/OS Administrator Guide.

§Restart§ Using All Runs of a Job Including Restarts

When processing ON PGMST blocks, Control-M can incorporate the results of all previous runs and restarts, filtering them for jobs restarted with the RESTART, RECAPTURE CONDITION, and ABEND CODES parameters. Control-M/Restart searches previous runs to determine which steps must be considered part of the restarted job.

For example, if one step finished successfully during its original run and another step finished successfully after a restart, the ON block check for the successful finish for both steps produces a TRUE result and the ON statement is satisfied.

Activation of this facility requires that the ALLRUNS parameter in the CTRPARM member be set to YES. When activated, this facility can apply to any specified step, step range, or to the ON PGMST step value +EVERY. §Restart§

Step Values

PGMST

Within an ON PGMST statement, the specified step is generally a program step, specified in the PGMST field. It may be a program executed directly within the job stream, in which case no PROCST value is specified, or it may be a program executed by a called procedure, in which case the called procedure is specified in PROCST.

If the JCL contains nested procedures, the name of the EXEC procedure statement that invokes the most deeply nested procedure, that is, the procedure that immediately invokes the PGM step, must be specified in PROCST.

The same step name can appear in different ON PGMST statements in the same ON PGMST block, or in different ON PGMST blocks.

STEP RANGE

To check codes in a range of steps, first define the step range and assign it a name in the STEP RANGE statement, which is described in Step Name: +EVERY. Then specify the name, preceded by an asterisk, in the PGMST field. The * indicates that the specified name is a range name, not a step name. The range of steps is displayed, and you can check the codes that are displayed within the defined range.

If the LASTSTEP parameter is set to Y in the CTMPARM member, Control-M treats the job step named $LAST as the job step executed last, and the job step named $FIRST as the job step executed first.

If Control-M adds a Control-M/Restart step to a job, for example, if a job is restarted by Control-M/Restart, or if PREVENT NCT2 is specified in the job scheduling definition, the Control-M/Restart step is processed like all other job steps.

Control-M does not treat the Control-M/Restart step or any FLUSHED step as the step executed last or first.

ON PGMST ANYSTEP  PROCST          CODES C****  U**** S***              A/O
DO OK
ON PGMST $LAST    PROCST          CODES >C0000 U**** S***              A/O  
DO NOTOK

Step Name: ANYSTEP

You can specify ANYSTEP as the value in the PGMST field. In general, it indicates that the DO statements must be performed if the specified codes are found in any steps.

For the interaction of ANYSTEP with the action DO OK, see General Information for DO OK.

However, if ANYSTEP is specified with codes OK, NOTOK, EXERR, JLOST, JNRUN, JSECU, JNSUB or *UKNW, the ON criteria are satisfied only if the entire job ends with the specified code criteria.

If ANYSTEP is specified with code FORCE, no other codes can be specified in the same ON block, and the PROCST parameter must be left blank. For a description of code FORCE, see CODES Values.

Step Name: +EVERY

The value +EVERY is used without being accompanied by limiting step values when the code criteria must be satisfied for every step. The following examples all have the same impact – the code criteria must be satisfied for every step in the job without exception.

Value +EVERY is generally accompanied by a limiting step value when the code criteria must be satisfied for every step within the specified limits, as follows:

• If the limiting value is a PROCST value, the code criteria must be satisfied by all job steps from within the specified procedure.

  ON PGMST +EVERY PROCST STEP1

  Every program step of procedure step STEP1 must be satisfied.

• If the limiting value is a PGMST value, the code criteria must be satisfied by all executions of the specified job step (or range of steps if a range is specified), from within the job steam and within all procedures.

• • ON PGMST StepA PROCST +EVERY

    All executions of job step STEPA from within the job stream and within every procedure must be satisfied.

  • ON PGMST *Range1 PROCST +EVERY

    Executions of all job steps in Range1, from within the job stream and within every procedure, must be satisfied.

    Step name +EVERY can be specified with the following codes: Cnnnn, Sxxx, Unnnn, *xxxx, FLUSH, SNRUN and *****.

• When step name +EVERY is specified with codes Cnnnn, Sxxx, Unnnn and *xxxx, the following conditions must be satisfied to satisfy the ON statement:

  • If the steps that run (excluding FLUSH steps) satisfy the PGMST and PROCST criteria, they must also not contradict the Cnnnn, Sxxx, Unnnn or *xxxx codes.

  • At least one step runs and fulfills the above conditions.

• When step name +EVERY is specified with codes FLUSH, SNRUN or *****, the following apply:

  • ON PGMST +EVERY CODES FLUSH is satisfied if in each job step, a JCL COND or JCL IF/THEN/ELSE statement caused the step not to run.

  • ON PGMST +EVERY CODES SNRUN is satisfied if each job step did not run.

  • ON PGMST +EVERY CODES ***** is satisfied if each defined job step ran and no job step was flushed (that is, due to a JCL COND or JCL IF/THEN/ELSE statement).

• Force Control-M to end a job with a NOTOK status when every step in the job is flushed:

  Copy

  ON PGMST +EVERY   PROCST          CODES FLUSH                       A/O A
  ON PGMST xxx      PROCST          CODES FLUSH                       A/O 
    DO NOTOK

  where the xxx is any one of the actual step names in the job stream that can be flushed.

Job completion code: +JOBRC

JOBRC allows the user to assign a completion code for the entire job based on the completion codes of its steps. z/OS 1.13 allows the user to set the job’s completion code in the JCL JOB statement using the JOBRC parameter. This parameter determines how the JOBRC is calculated from the completion codes of its steps.

The parameter has the following options:

• The highest return code from the steps (the default) – this is the same as how Control-M assigned the job’s completion code prior to z/OS 1.13. If the job's execution fails because of an ABEND, the job completion code is set to the last ABEND code.

• The return code of the last step - in this case the job’s completion code is based on the completion code of its last executed step.

• The return code of a specific step - in this case the job’s completion code is based on the completion code of a specific step identified by its name.

Control-M extracts the JOBRC, which is calculated by JES2 or JES3 based on the JOBRC parameter specified in the JCL JOB statement, and use it for the job analysis during post processing.

An ON PGMSTEP +JOBRC statement can specify any DO action to be processed when the extracted JOBRC fits the codes specified in the statement. JOBRC is extracted in all z/OS releases (in releases earlier than z/OS 1.13, it is set equal to MAXRC) so ON PGMSTEP +JOBRC can be handled in any z/OS release.

In some special situations Control-M does not extract the JOBRC. Either Control-M is not able to extract JOBRC (when JOBRC not supplied by z/OS or JES), or it is assumed that users do not require that Control-M extract JOBRC (when the results based on JOBRC would be different than what users actually need). Some special situations are described in the following examples:

• The job execution was terminated by the 'Cancel' operator command.

• The job execution was terminated prematurely according to the COND= parameter specified in the JOB JCL statement.

• The job execution is the restart run performed by Control-M/Restart and the ALLRUNS Control-M/Restart installation parameter, which specifies whether Control-M considers during post processing all the previous runs of a job, is activated.

If JOBRC is not extracted, the ON PGMSTEP +JOBRC statement is ignored.

An ON PGMSTEP +JOBRC statement cannot be connected by AND/OR Boolean relationships with other ON PGMSTEP statements.

Since JOBRC is not used for evaluating the OK/NOTOK status of job when DO OK/NOTOK actions are defined in the ON PGMSTEP statements of step(s), DO OK/NOTOK actions in ON PGMSTEP +JOBRC cannot be defined together with DO OK/NOTOK in the ON PGMSTEP statements of step(s).

CODES Values

CODES can be condition codes, user abend codes, system abend codes, various end codes and statuses, and certain keywords. They can also be prefaced by certain qualifiers. All of these are described below.

A maximum of 245 values can be specified for CODES in any ON PGMST statement, as follows:

• Each line of an ON PGMST statement contains fields for specification of up to four values for CODES.

• Whenever a fourth value is specified on a line for CODES, and Enter is pressed, a new line within the same ON PGMST statement is opened, allowing specification of as many as four additional CODES values.

Valid CODES Values

Table 202 ON PGMST Parameter CODES Values

FLUSH

The CODES value FLUSH generally applies when a step does not run but no error is indicated. This CODES value is assigned in the following cases:

• A JCL COND or JCL IF/THEN/ELSE statement caused the step not to run. Control-M detects CODES value FLUSH steps by message IEF272I (Step was not executed).

• §Restart§ If a job was restarted by Control-M/Restart, and Control-M is to consider all job runs during post-processing (the ALLRUNS parameter is set to YES in the CTRPARM member), a step is defined as FLUSH if:

  • either the step did not previously run, or Control-M/Restart did not recapture a completion or abend code from a previous run

    and either

  • it was not executed during the RESTART run because of a JCL COND or JCL IF/THEN/ELSE statement

    or

  • it was not executed due to a RESTART decision (message CTR103I)

Because a CODES value of FLUSH does not indicate that an error occurred during job execution, assignment of this status does not cause a job status of NOTOK.

If a JCL statement other than the COND or IF/THEN/ELSE statement caused the step not to run, it is not defined as a FLUSH step.

If the failure of a step causes subsequent steps not to be executed, these subsequent steps are not defined as FLUSH steps.

For reasons of backward compatibility, that is, to ensure that the application of CODES value ***** remains unchanged, CODES value ***** does not include FLUSH steps.

SNRUN

A step is defined as CODES value SNRUN if it did not run. This code includes

• any step with a CODES value of FLUSH

• any step that does not appear in the job

• instances where a step does not run because of a JCL error in a prior step (the step with the JCL error does not have a status of SNRUN)

• §Restart§ if a job was restarted by Control-M/Restart, and Control-M is to consider all job runs during post-processing (the ALLRUNS parameter is set to YES in the CTRPARM member), a step is defined as SNRUN if one of the following conditions are satisfied:

  • The step did not previously run, or Control-M/Restart did not recapture a completion or abend code from a previous run.

  • The step was not executed during the RESTART run.

SNRUN cannot be specified together with ANYSTEP. Because SNRUN includes steps that do not exist in a job, and ANYSTEP includes all step names even if they do not exist in a job, specifying both in the same job causes a condition that SNRUN cannot process.

A status of SNRUN does not indicate that an error occurred during a job execution, nor does it cause a job status of NOTOK. It merely indicates that it did not run.

For reasons of backward compatibility, that is, to ensure that the application of CODES value ***** remains unchanged, CODES value ***** does not include SNRUN steps.

FCnnn

The DO actions are performed after a specified number of job or Smart Table failures (any case of finishing NOTOK) occur serially. The number of failures is specified by the 3-digit suffix of the FCnnn parameter. The DO action is performed only after the number of failures that are specified by FCnnn occur. If afterwards there are additional failures, the DO action will not be performed again.

Every time the job or Smart table ends with a success, or is forced to be ENDED OK by a FORCE OK request, the failure counter is reset to zero.

ON PGMST ANYSTEP     PROCST        CODES FC001                          A/O A
ON PGMST xxx         PROCST        CODES yyyy                            A/O
  DO do-statements

Code Qualifiers and Relationships

Any character in a condition code, system abend code or user abend code may be replaced by an asterisk (*). An asterisk means "any value" for the character it replaces. For example, if S*13 is specified, the code criteria for the step is satisfied by codes S013, S613, S913, and so on.

The qualifiers described in Table 203 can be used in certain cases.

Table 203 ON PGMST Parameter Code Qualifiers

The relationship between multiple codes in an ON PGMST statement is OR, that is, the appearance of any of the codes in the specified step satisfies the ON criteria, except for range specifications such as >C0010 or <C0040.

However, code criteria qualified by N take precedence over all other code criteria. If a code that is specified with an N qualifier is generated by the specified step, accompanying DO actions are not performed even if other ON code criteria are satisfied.

ON PGMST statement types

The two types of ON PGMST statements are

• Step-level - depend on the results of specific jobsteps

• Job-level - depend on the results of the entire job

Step-level ON PGMST statements have CODES values like Cxxxx, Sxxx and/or Uxxx and can be coded with specific PGMST and PROCST values (or ANYSTEP).

Job-level ON PGMST statements have CODES like OK, NOTOK and EXERR that apply to the results of the entire job. These can ONLY be coded with PGMST of ANYSTEP.

Control-M Post Processing is performed in two stages. The first stage checks individual steps against the Step-level ON PGMST logic. In this stage, Control-M also determines the OK/NOTOK status of the job, based on the individual steps.

In the second stage, Control-M checks the Job-level ON PGMST logic.

Since mixing Step-level and Job-level type CODES might produce unexpected results, BMC recommends that you avoid mixing the two types.

Examples for ON PGMST

• If >C0008 NC0020 is specified, the codes criteria is satisfied (and the DO statements performed) by the appearance of any condition code greater than 8 except condition code 20.

• If the following are specified:

  Copy

  >U0999 NU1341 S*** NS*37 <C0004

  The DO actions are triggered by one of the following:

  • a condition code less than C0004

  • a user abend code greater than U0999 except U1341

  • any system abend code except Sx37 (that is, except S037, S137, and so on)

• If only code NC0008 is specified:

  The accompanying DO statements are never performed. The specified value only indicates when not to perform the DO actions. There is no indication when the DO actions are to be performed.

JOB: PRDKPL01 LIB CTM.PROD.SCHEDULE                          TABLE: PRODKPL
COMMAND ===>                                                SCROLL===> CRSR
+-------------------------------------------------------------------------+
  OUT                                                                      
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS             
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP              
  SYSOUT OP   (C,D,F,N,R)                                              FROM
  MAXRERUN     RERUNMEM                              INTERVAL       FROM   
  STEP RANGE         FR (PGM.PROC)          .            TO          .     
  ON PGMST ANYSTEP  PROCST UPDA     CODES C0008  C0016                  A/O
    DO OK                                                        
    DO                                                                     
  ON PGMST          PROCST          CODES                               A/O
    DO                                                                     
  ON SYSOUT                                          FROM 001 TO 132    A/O  
    DO                                                                
  ON VAR                                                              
    DO                                                                
  SHOUT WHEN           TIME       +     DAYS     TO                 URGN   
    MS                                                                     
======= >>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<< =====
                                                                           
                                                                           
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                                15.16.03

JOB: PRDKPL02 LIB CTM.PROD.SCHEDULE                         TABLE: PRODKPL
COMMAND ===>                                               SCROLL===> CRSR
+------------------------------------------------------------------------+
  OUT                                                                     
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS            
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP             
  SYSOUT OP   (C,D,F,N,R)                                             FROM
  MAXRERUN     RERUNMEM                              INTERVAL      FROM   
  STEP RANGE         FR (PGM.PROC)          .          TO         .       
  ON PGMST STEP08   PROCST UPDA     CODES <C0008                       A/O
    DO OK                                                        
    DO                                                                    
  ON PGMST          PROCST          CODES                              A/O
    DO                                                                    
  ON SYSOUT                                         FROM 001 TO 132    A/O  
    DO                                                                
  ON VAR                                                              
    DO                                                                
  SHOUT WHEN           TIME       +     DAYS     TO                URGN   
    MS                                                                    
====== >>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<<< ====
                                                                          
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                               15.16.03

JOB: PRDKPL03 LIB CTM.PROD.SCHEDULE                         TABLE: PRODKPL
COMMAND ===>                                               SCROLL===> CRSR
+------------------------------------------------------------------------+
  OUT                                                                     
  AUTO-ARCHIVE Y          SYSDB    Y      MAXDAYS      MAXRUNS            
  RETENTION:  # OF DAYS TO KEEP 030  # OF GENERATIONS TO KEEP             
  SYSOUT OP   (C,D,F,N,R)                                            FROM 
  MAXRERUN     RERUNMEM                              INTERVAL     FROM    
  STEP RANGE         FR (PGM.PROC)          .          TO        .        
  ON PGMST *DF2     PROCST          CODES S***   U****  NU2030         A/O
    DO RERUN                                                     
    DO SHOUT     TO  TSO-P43            URGENCY R                
     = JOB PRDKPL03 ABENDED; THE JOB IS RERUN                    
    DO                                                                    
  ON PGMST          PROCST          CODES                             A/O 
    DO                                                                    
  ON SYSOUT                                        FROM 001 TO 132    A/O  
    DO                                                                
  ON VAR                                                              
    DO                                                                
  SHOUT WHEN           TIME       +     DAYS     TO                URGN   
    MS                                                                    
====== >>>>>>>>>>>>>>>>> END OF SCHEDULING PARAMETERS <<<<<<<<<<<<<< =====
                                                                            
 COMMANDS: EDIT, DOC, PLAN, JOBSTAT                               15.16.03