Selected Implementation Issues

This chapter includes the following topics:

• Overview of Implementation Issues

• Job Ordering Methods

• Manual Conditions File and Maybe Jobs

• Parameter Prompting Facilities

Overview of Implementation Issues

This chapter provides you with concepts and hints for successful implementation of Control-M. It also provides a detailed description of the procedures required for implementation of Control-M by the user and operator. The following implementation concepts and instructions are discussed in this chapter:

• alternative methods of job ordering

• Manual Conditions list and Maybe jobs

• MAINVIEW Batch Optimizer (MVBO) considerations

• parameter prompting facilities

For information about the INCONTROL administrator's implementation of Control-M, see the INCONTROL for z/OS Administrator Guide.

Job Ordering Methods

Under Control-M, job ordering is normally performed automatically by the New Day procedure and User Daily jobs during New Day processing, as described in detail in the INCONTROL for z/OS Administrator Guide.

However, at times it is desirable to perform job ordering using methods other than the New Day procedure and User Daily jobs. For example, it may be necessary to schedule special purpose jobs, or to order jobs for a different working date.

Control-M provides several alternative methods of job ordering. Some methods of job ordering are performed online; others in batch. Some are performed automatically, while others are performed manually.

Below is a list of facilities and functions that enable jobs to be ordered without the New Day procedure and User Daily jobs.

Table 261 Alternative Job Ordering Methods

Job Ordering Through Quick Submit Command CTMQSB

In many instances, the contents of the job are determined by an end user before submission. For example, a user may maintain a member that contains the JCL and parameters of a certain report. When someone requests the report, the user edits the member, possibly using ISPF, changes the parameters of the report, and uses the ISPF SUBMIT command to submit the job.

As described in the previous paragraphs, Control-M can detect such jobs when they appear on spool, and control their execution. However, there are a few disadvantages to this method. The primary disadvantage is in handling job abends. When an On Spool job abends, it is not clear which JCL member must be submitted to perform a rerun. For example, in the above example, if the JCL has not been saved, such as where the user exited ISPF EDIT using the CANCEL command, there is no original member from which to perform the rerun.

This problem can be overcome using Control-M command CTMQSB. When submitting a job, use command CTMQSB instead of the regular ISPF SUBMIT command. Just type it in the command line and press Enter. You may have to prefix it by the % character to designate a CLIST.

It is possible to replace the ISPF SUBMIT command with the Control-M CTMQSB command. For more information, see the description of installing ISPF support in the Control-M Installation Procedure in the INCONTROL for z/OS Installation Guide.

If the member contains JCL cards that start with //*CONTROLM then special processing takes place, that is, the member is not submitted. The Control-M submit command looks for two //*CONTROLM cards with the following format (order and position in the job are not important):

//*CONTROLM TABLE scheduling-tables-library table-name
//*CONTROLM JCL JCL-library

The current JCL member is written to the specified JCL library. The name of the member is composed of the first three letters of the TSO user ID, and the Control-M order ID (5 characters). This method ensures that the name is unique.

The table is read from the specified library. The submit command assumes that the table contains only one job scheduling definition. If the table contains definitions for more than one job, only the first job scheduling definition is taken into account; the remainder are ignored. The CTMQSB Control-M command replaces the original library and member names with the names of the JCL library and member where the job has been stored, as described in the preceding section. If the WM1822 optional wish is applied, the user ID (OWNER) of the job is replaced by the TSO user ID. The WM1822 optional wish is in the IOADFLT member in the IOA IOAENV library.

To avoid accumulation of old members, it is advisable that a new, empty JCL library be used each day.

Control-M job order security exit CTMX001 is invoked (as under CTMJOBRQ). If the job order is valid, it is placed on the Control-M Active Jobs file. The job is then submitted based on the regular job scheduling criteria, such as IN, CONTROL, TIME.

Tables that are referred to by //*CONTROLM statements must not be included in a batch User Daily or in New Day processing. They must contain a skeleton of a job order, such as reports that require IMS to be up, reports that use substantial IDMS resources, update to certain VSAM files, and so on.

It is possible to force the use of the Control-M submit facility. When the Control-M CTMQSB command is activated, the contents of the member to be submitted are passed to Control-M User Exit CTMX010. This exit can automatically add //*CONTROLM cards to the submitted member. Use of this technique results in a completely scheduled environment. All submitted jobs are under Control-M control.

Special Purpose Job Ordering from Special Environments: CTMAJO

Warning: CTMAJO functionality, which is used to order jobs from various environments, such as CICS or ROSCOE, is no longer supported by Control-M. BMC recommends that you use the CTMBLT utility (which provides improved functionality) instead of CTMAJO. You use the CTMBLT utility to dynamically build job scheduling definitions and to order individual jobs when required. For more information, see the INCONTROL for z/OS Utilities Guide.

Manual Conditions File and Maybe Jobs

The Manual Conditions file contains a list of prerequisite conditions that are required by jobs in the Active Jobs file but which are not available, that is, added to the IOA Conditions file, unless there is some form of user intervention.

Loading the Manual Conditions File

Conditions are added to the Manual Conditions file through the IOALDNRS utility. This utility is run during New Day processing, but it must also be run following the addition of a set of jobs in the Active Jobs file.

The IOALDNRS utility checks the IN conditions required by scheduled jobs against the conditions available in the IOA Conditions file and against the OUT conditions that can be set by the scheduled jobs.

All IN conditions that are not in the IOA Conditions file and that are not listed as OUT conditions in a scheduled job are added to the Manual Conditions file.

Using the Manual Conditions File

The Manual Conditions file provides the user with a list of conditions for which manual intervention is required if the conditions are to be added to the IOA Conditions file.

To utilize this list effectively, the user must distinguish between two types of conditions in the list because each requires a different type of intervention. From the user perspective, the two types of conditions are:

• Manual Conditions

  Conditions that always require manual intervention and are therefore never automatically added by jobs as OUT or DO COND conditions.

  Job-X, which requires that a tape has arrived before the job is submitted, contains IN prerequisite condition TAPE-ARRIVED.

  This condition must not be automatically added to the IOA Conditions file by a job, but must instead be manually added by the operator only after the tape has arrived.

• Unscheduled Conditions

  Conditions that can be added automatically by a job, but which appear in the Manual Conditions list because none of the jobs scheduled that day set the condition.

  Job-B requires IN condition JOB-A-ENDED-OK. This condition is added as an OUT condition by Job-A. Job-B is scheduled on a day during which Job-A is not scheduled.

  The distinction between the two types of conditions mentioned above is important because each type requires a different user response, as described below.

Handling Manual Conditions

The handling of Manual Conditions, as defined above, is fairly straightforward. In the above example, the user clearly does not want the condition added automatically, nor does the user want the condition ignored. Simply put, Job-X must not be run unless the required tape has arrived at the site, in which case the operator adds the condition. For this type of condition, the only desired manual intervention is the adding of the condition at the appropriate time. This can be performed by option A (Add) in the Manual Conditions screen.

Handling Unscheduled Conditions

The handling of Unscheduled Conditions, as defined above, is more complex because it concerns the issue of normal dependency versus "Maybe" dependency:

• Normal Dependency

  A successor job is always dependent on the predecessor job, regardless of whether the predecessor job is scheduled.

  With this type of dependency, using the example cited above, successor Job-B must not be submitted because predecessor Job-A was not scheduled and executed.

  In this case, the dependency must not be ignored. The unscheduled prerequisite condition is not added manually.

• "Maybe" Dependency

  A successor job is dependent on the predecessor job only if the predecessor job is scheduled that day. If the predecessor job is not scheduled that day, the successor job can still be submitted, provided that other runtime scheduling criteria are satisfied.

  In this case, the predecessor job is referred to as a Maybe job.

  With this type of dependency, using the example cited above, successor job Job-B must be submitted, provided all other runtime scheduling criteria are satisfied, because predecessor job Job-A was not scheduled.

  In this case, the dependency must be ignored or bypassed. Methods for ignoring Maybe dependencies are described below.

Handling Maybe Dependencies

The most common method of handling Maybe job dependencies is to add the unscheduled conditions of Maybe jobs to the IOA Conditions file.

However, examining each condition in the Manual Conditions list to determine if it is an unscheduled condition from a Maybe job, and manually adding each Maybe job unscheduled condition, is a difficult process. The process can be greatly simplified and automated, by following these steps:

1. Define a Unique Prefix for Maybe Job Prerequisite Conditions

   When Maybe dependencies are defined, the prerequisite IN, OUT and DO COND conditions must all have the same unique prefix (that is, a prefix that is not used for other prerequisite conditions).

   Using a unique prefix symbol makes it easier to see unscheduled conditions of Maybe Jobs in the Manual Conditions list.

   Normally, this prefix is either symbol # or @.

   If your site utilizes MVS restarts and uses symbol @ in OUT conditions for the restart, this symbol must not be used as a prefix for Maybe job conditions. In this case, use the # symbol for Maybe conditions. For details, see MVS Job Restart Without Control-M/Restart.

2. Use the ADDCOND7 KeyStroke Language utility to add the prerequisite conditions. The ADDCOND7 KSL utility automatically adds all conditions with a specified prefix in the Manual Conditions file to the IOA Conditions file. The ADDMNCND JOB member in the IOA JCL library can be used as a sample for running the KSL.

   By specifying the above-defined unique prefix symbol in the utility, unscheduled conditions from Maybe jobs are automatically added, making manual adding of the conditions unnecessary.

After the above two steps have been implemented, the only manual intervention required for unscheduled conditions of Maybe jobs is the executing of the ADDCOND7 KSL utility.

Maybe Jobs in SMART Tables

The above implementation for handling unscheduled conditions of Maybe jobs can be applied to jobs and conditions.

However, an alternative method is available for conditions and jobs in SMART Tables. Rather than add the unscheduled conditions of Maybe jobs to the IOA Conditions file, the unscheduled conditions can be removed as runtime scheduling criteria for the successor job orders.

The SMART Table Entity definition in SMART Tables contains an ADJUST CONDITIONS field. If a value of Y is specified in the ADJUST CONDITIONS field, Control-M checks the scheduled jobs for unscheduled conditions.

Unscheduled conditions normally added by other jobs in the same SMART Table are removed from the IN statements of the scheduled job orders:

• These conditions do not appear in the Zoom screen. They are not, however, deleted from the original job scheduling definition.

• These conditions also do not appear in the Manual Conditions file. Therefore, there is no real advantage to defining them with a unique prefix, unless they are used as IN conditions for jobs in a different table.

For more information, see Job Production Parameters.

MAINVIEW Batch Optimizer Considerations

MAINVIEW Batch Optimizer (MVBO) is a batch optimization system that enables effective parallel processing and efficient resource utilization in the mainframe environment. The Job Optimizer Pipes component of MVBO enhances this capability using MVS Pipe technology. If MVBO/Job Optimizer Pipes is installed at your site, you can include the Control-M PIPE parameter in a job scheduling definition in order to use MVBO/Job Optimizer Pipes functionality.

Job-Related Considerations for Pipes

The following job-related issues must be considered when using the PIPE parameter in a Control-M job scheduling definition:

• When using pipes for jobs submitted by Control-M, the PIPE parameter must be used if parallel submission of all pipe participants is to be ensured.

• Normally (that is, when pipes are not used), prerequisite conditions ensure desired flow of predecessor and successor jobs.

  However, when values are specified in the PIPE parameters of interrelated job scheduling definitions, Control-M uses them to create Collections. The jobs in a Collection are not submitted until all prerequisite conditions required by all jobs in the Collection are satisfied. If a dependency exists between an OUT condition of one job and an IN condition of another job in the same Collection, it prevents submission of all the jobs in the Collection. Control-M resolves this problem by ignoring the IN condition, thus bypassing the dependency between the jobs in the Collection and enabling the submission of the jobs. If the job is removed from the Collection, its ignored IN conditions reappear.

• When two jobs in the same Collection request the same Control resource, and at least one of them requests the resource in "exclusive" mode, a "deadlock" situation arises—the Collection jobs are not submitted. To prevent this, Control-M ignores the Control resource requests of one of the jobs, as follows: If one of the jobs requested the resource in "shared" mode, that resource request is ignored; if both jobs requested the resource in "exclusive" mode, the resource request of the job with the shorter average elapsed time is ignored. If the job is removed from the Collection, its ignored Control resources reappear.

  To allow integration between Control-M and MVBO/Job Optimizer Pipes, the pipe name specified in the Control-M job scheduling definition must be identical to the pipe name specified in the MVBO/Job Optimizer Pipes rule. Currently, this requirement is not forced by Control-M.

• Jobs cannot be run in parallel if TIME FROM and TIME UNTIL specifications for the jobs do not overlap.

  This case must be considered individually at time of implementation.

• When PIPE definitions are added, the Quantitative resources defined for the jobs in the Collection must be checked to see if some of the defined resources are no longer necessary. For example, if a pipe replaces a tape data set, the tape resource may not be required. Such resources must be removed from the job scheduling definition.

• In a non-Sysplex environment, all jobs that are part of a Collection must run in the same system. Therefore, BMC recommends that you avoid using resources prefixed by a dollar sign ($) in jobs that are part of a Collection, to ensure that all the jobs are submitted to the same system.

Enhanced Runtime Scheduling Algorithm

When jobs that are part of a Collection are scheduled, Control-M treats the Collection as one unit of work for processing runtime scheduling criteria in the following ways:

• Control-M ensures that the required number of participants, as defined for the pipe in the MVBO/Job Optimizer Pipes rule, access each pipe in the Collection. If a participant is missing, the jobs in the Collection are not submitted. This ensures that a job is not submitted when its participants are not scheduled on that day.

• Control-M analyzes all resources, such as prerequisite conditions, Quantitative resources, and time limits, required by all jobs in the Collection as a single set. All participants are submitted together when all the resources required by the set are available. This ensures the parallel submission of all pipe participants.

  To ensure that the jobs begin execution on time, it is recommended that initiators be handled as Quantitative resources. This ensures that submitted jobs do not wait for initiators and delay other jobs in the Collection.

• Control-M checks if the MVBO/Job Optimizer Pipes monitor is active before submitting the jobs in the Collection. If the MVBO/Job Optimizer Pipes monitor is not active, the jobs in the Collection are not submitted. This ensures that, when submitted, the jobs run in parallel, using pipes.

System-Related Considerations

The following system-related issues must be considered when using the PIPE parameter in a Control-M job scheduling definition.

• Parallel processing changes resource usage in the system. All resources required for all the jobs in the Collection must be available when the jobs are submitted.

  This means that more resources, such as initiators, tape drives, CPUs, are required for shorter time periods; they become available after the jobs using the pipe finish execution. Therefore, when using pipes, resource usage in the system in which the jobs are to run must be reviewed to ensure that all required system resources are available at the time the jobs are submitted.

• The change in resource usage may necessitate changing the maximum quantities defined for Control-M to satisfy the changed requirements.

Parameter Prompting Facilities

It is assumed that the reader is familiar with the following Control-M facilities and concepts:

• JCL and AutoEdit facility

• prerequisite conditions

• Manual Conditions (Screen7) and the IOALDNRS utility

Control-M provides two different types of Parameter Prompting facilities. The online use of the two Parameter Prompting facilities is described in Online Facilities.

This chapter provides an explanation of how the Parameter Prompting facilities work, how they differ from each other, and how to choose the facility that best suits your operational needs. In addition, certain preparatory steps are detailed.

Parameter Prompting Facility: Type 1

The Parameter Prompting Facility: Type 1 is an ISPF table-based facility that provides automatic prompting for AutoEdit parameter values and setting of prerequisite conditions. It is the recommended method for operations personnel to automate the updating of AutoEdit parameter members.

The Control-M JCL and AutoEdit facility eliminates the need for frequent manual changes to job parameters. However, there are usually a few job parameter changes that cannot be automated, for example, tape serial numbers, which are unknown prior to tape arrival. These types of parameters require manual modification by the user, generally operations personnel.

Old Method

To illustrate how prior versions of Control-M solved this problem, consider the daily arrival of IRS tape number 123456.

Figure 373 Illustration 1A: How Control-M Formerly Handled A New Tape

The illustration above represents the one-time definitions required to prepare Control-M for handling the IRS tape.

1. JOBA requires input of the IRS tape number before it can run. The job must be defined in a Control-M table with an IN prerequisite condition of IRS-TAPE-ARRIVED.

2. The JCL for JOBA must include %%LIBSYM and %%MEMSYM control statements pointing to the AutoEdit Library CTM.LIB.SYMBOLS and the AutoEdit member TAPES.

3. The AutoEdit member TAPES contains several AutoEdit parameters (from various jobs), including the parameter %%IRS_TAPE.

   On a given day, the Manual Conditions file created by the IOALDNRS utility indicates that the prerequisite condition IRS-TAPE-ARRIVED must be added manually by the user. This serves as a reminder to the operations personnel that a job is waiting for an IRS tape number. When the tape arrives, the user must perform two steps, as illustrated in the following figure:

   Figure 374 Illustration 1B: Steps Formerly Performed by the User

   

4. Access the AutoEdit member TAPES and assign value 123456 to the %%IRS_TAPE parameter.

5. Enter Screen 7 to manually add condition IRS-TAPE-ARRIVED.

When the condition IRS-TAPE-ARRIVED has been added to the IOA Conditions file, and assuming all other runtime conditions are met, the Control-M monitor submits the job. When the job is submitted, the value of %%IRS_TAPE in the JCL of JOB A is updated by the value in the TAPES member. The job parameter VOL=SER=%%IRS_TAPE resolves to VOL=SER=123456.

New Method

In the current version, the same problem is resolved in a different way using the Parameter Prompting Facility: Type 1.

Figure 375 Illustration 2A: How Control-M Now Handles aNew Tape

The illustration above represents the one-time definitions required to prepare Control-M for handling the IRS tape when using Parameter Prompting Facility: Type 1.

1. JOBA requires input of the IRS tape number before it can run. The job must be defined in a Control-M table with IN prerequisite condition IRS-TAPE-ARRIVED.

2. The JCL for JOBA includes %%LIBSYM and %%MEMSYM control statements pointing to the Control-M PROMPT prompting parameters library and the TAPM%%OMONTH.%%ODAY daily AutoEdit member.

3. Using the first option of the Parameter Prompting Facility: Type 1, groups of AutoEdit parameters that require value assignment are defined once. These parameters are grouped into a Master Prompting table, the Master table. Default parameter values may be assigned. In addition, prerequisite conditions to be associated with parameters are designated. In this example, several parameters from various jobs have been defined in the TAP Master table, including the %%IRS_TAPE parameter from JOBA. Prerequisite condition IRS-TAPE-ARRIVED has been associated with this parameter.

When the tape arrives, the user only performs one step (illustrated below):

Figure 376 Illustration 2B: Single Step Now Performed by the User

The user selects the TAP table from a list of Master tables and is presented with Daily Prompting table TAPT1112, an automatically created copy of the Master table for the current date. The Daily Prompting table consists of parameter names, (optional) descriptions, and default values. The user updates the %%IRS_TAPE parameter with the value 123456.

The facility automatically adds condition IRS-TAPE-ARRIVED to the IOA Conditions file and updates the daily AutoEdit member TAPM1112.

Summary

By using Parameter Prompting Facility: Type 1, it is only necessary to update the Daily table. The user no longer needs to remember which AutoEdit parameters in which AutoEdit symbol member require changing, nor the prerequisite conditions that require setting. The Parameter Prompting facility automatically handles updating of the AutoEdit member, and adds any required conditions to the IOA Conditions file.

Usage Notes

• The PLAN NAME can be up to six characters in length. Use of the SUFFIX parameter in the FETCH phase permits creation of multiple Daily User Prompting Plans based on one Master Prompting Plan. This also makes it possible to duplicate (by overriding) a fetch of the same plan by setting the OVERRIDE DAILY PLAN parameter to YES on the FETCH A PLAN screen.

• Each job defined in the Master Scheduling table must contain an IN prerequisite condition in the format:

  Copy

  RUN-%%PLANID

  This prerequisite condition is added during the EXEC phase only after all parameters for a specific plan are assigned in the EXEC phase. %%PLANID resolves to the PLAN NAME (and SUFFIX) designated in the FETCH phase.

  Since each plan can be ordered multiple times for the same scheduling date, it is highly recommended to distinguish between the dependencies of the jobs in the plan based on PLAN NAME. Every prerequisite condition used for inter-plan dependency must contain the string %%PLANID. It is automatically replaced by the PLANID during the FETCH phase.

• The JCL of each job must be modified as follows:

  The first AutoEdit control statement must point to an AutoEdit Parameters library and the PLANID member. The PLANID member contains the unique PLANID of the job (automatically handled by Control-M).

  Copy

  %%LIBSYM CTM.PROD.SYMBOLS %%MEMSYM PLANID

  The second AutoEdit control statement must point to the Daily AutoEdit Parameters library and the member %%PLANID. Control-M automatically resolves %%PLANID to the PLAN NAME designated in the FETCH phase.

  The Daily AutoEdit Parameter library must be suffixed by a date parameter that is resolved by Control-M.

  Copy

  %%LIBSYM CTM.PROD.AEDI%%OMONTH.%%ODAY %%MEMSYM %%PLANID

• The %%PLANID member of each plan (in the Daily AutoEdit Parameter library) contains up to four configuration tables identified by AutoEdit variables.

  Parameters and data that are repeatedly used in a data processing environment can be defined in such a configuration table.

  A configuration table is a member of the GLOBAL library, which is referenced by the DAGLOBAL DDstatement. Such a member contains a set of user-defined local variables and their assigned values that can be referenced in the JCL of individual jobs.

  An AutoEdit variable identifies such a configuration table by a statement in the form %%CONFn=config_tablename in the %%PLANID member.

  Copy

  %%CONF1=INDICES
  %%CONF2=WEEKCHAR
  %%CONF3=
  %%CONF4=

  To use the configuration tables parameters procedure, insert the following AutoEdit statement in the JCL of each job:

  Copy

  //* %%INCLIB CTM.PROD.PARM %%INCMEM PPF2CONF

  The PPF2CONF member uses the configuration table values specified in the %%PLANID member to select the GLOBAL autoedit members to be included in the JCL of the job. It contains the following AutoEdit code:

  Copy

  %%IF *%%CONF1 NE *
  %%GLOBAL 
  %%CONF1    
  %%ENDIF             
  %%IF *%%CONF2 NE *
  %%GLOBAL 
  %%CONF2    
  %%ENDIF             
  %%IF *
  %%CONF3 NE *
  %%GLOBAL 
  %%CONF3    
  %%ENDIF             
  %%IF *
  %%CONF4 NE *
  %%GLOBAL 
  %%CONF4
  %%ENDIF

• The MEMLIB parameter of each job scheduling definition in the table must point to the Daily JCL library. The library name is suffixed by the AutoEdit date variables.

  Copy

  CTM.PROD.JCLP%%OMONTH.%%ODAY

• Occurrence numbering:

  It is recommended that all AutoEdit parameter names of jobs in the same plan be unique. In some plans, duplicate names may be unavoidable, and more than one job may share the same AutoEdit parameter name. If the parameters are to be assigned different values, that is, used for different purposes, each parameter must be assigned a different OCCUR NO during definition of the Master Prompting Plan.

  A %%SET statement specifying the OCCUR NO. must be included in the JCL of the associated jobs as follows:

  Copy

  %%SET %%OC# = 01

  When the AutoEdit parameter member is created, each AutoEdit parameter includes the OCCUR NO. as a suffix.

• Using the Parameter Prompting Facility: Type 2 requires customizing the Control-M submit exit (CTMX002). This exit does the following:

  • It ensures that at the time when the job is submitted, the AutoEdit Parameters library contains the PLANID member.

  • It places in the PLANID member an AutoEdit variable definition in the form

    Copy

    %%PLANID=plan_id

  • in order to provide the job with a unique identity (plan_id). This is done using an OUT condition in the job scheduling definition, as described in the source code of the exit.

  For information about modifying the exit, see the CTMX2PPF member in the IOA SAMPEXIT library.

Parameter Prompting Facility: Type 2

The Parameter Prompting Facility: Type 2 is a manual job scheduling facility that provides automatic prompting for AutoEdit parameter values. On a given day, the user selects the tables for execution. The user is then automatically prompted for parameter values required for the execution of the jobs scheduled to run on the specified date.

This type of prompting facility is recommended for use in a distributed environment where user departments are responsible for manually scheduling (ordering) their jobs, and specifying required parameters.

A sample application of this type of scheduling facility is the maintenance of confidential salary information in a payroll department. The payroll department usually retains control over its jobs and their input parameters.

The Parameter Prompting Facility: Type 2 has three major phases:

Definition Phase

Figure 377 Parameter Prompting Facility Type 2: Definition Phase

1. Table

   First, a table is defined using the Control-M Online facility. The table contains job scheduling information for all of a department’s jobs. Any number or type of jobs with any valid date scheduling criteria can be designated. The table is placed in a Master Scheduling Tables library.

2. Master Prompting Plan

   Next, using the first option of the Parameter Prompting Facility: Type 2, a Master Prompting Plan (MPP) is defined containing all AutoEdit variables used by all the jobs in the table. Any default values can be assigned. Value validity checks can also be defined. The MPP is placed in the Master Prompting Plan library.

FETCH Phase

Figure 378 Parameter Prompting Facility Type 2: Fetch Phase

The second option of the Parameter Prompting Facility: Type 2, FETCH A PLAN, allows the user to select a plan for execution by Control-M on a specific day.

When a FETCH option is executed for a specific PLANID, or all PLANIDs with a specific suffix, a daily table is automatically created. The Daily Scheduling table, a subset of the Master Scheduling table, is placed in the Daily Scheduling Tables library. The Daily Scheduling table contains the job scheduling definition of all of the jobs in the Master Scheduling table scheduled to run on the specified date, based on each job’s scheduling criteria.

The FETCH also creates a User Prompting Plan (UPP), a subset of the Master Prompting Plan, which is placed in the Daily Prompting Plan library. The UPP contains only parameters that are required by the jobs scheduled to run on the specified date.

A Daily JCL library is also created containing JCL for today’s jobs.

EXEC Phase

The third option of this facility, EXEC A PLAN, permits the user to update or accept the default values of all the parameters appearing in the daily UPP. A daily AutoEdit parameters member, which is accessed at the time of job submission, is automatically created and placed in the Daily AutoEdit Parameter library.

Figure 379 Parameter Prompting Facility Type 2: EXEC Phase

Once values have been assigned to all the parameters, the prerequisite condition RUN-%%PLANID is added. %%PLANID is resolved to the PLANID, and suffix if supplied, designated in the FETCH phase.

The Daily Scheduling table is then ordered by Control-M. The jobs are placed on the Active Jobs file and run based on their scheduling parameters; that is, a job is submitted only when all scheduling criteria, such as other prerequisite conditions, have been met.

Tailoring to User Needs

The Parameter Prompting Facility: Type 2 is usually activated from the Control-M ISPF Utilities screen. However, it is possible to activate the FETCH and EXEC phases using the following CLISTS:

Table 262 Parameter Prompting Facility Type 2: Use of CLISTS

CTMFETCH CLIST

When CLIST CTMFETCH is activated, the FETCH A PLAN screen is displayed:

Figure 380 The FETCH A PLAN Screen

---- CONTROL-M - P.P.F. ------ FETCH A PLAN ----------------------(P.2)
COMMAND ===>                                                           

   PLAN NAME              ===>                                         

   PLAN NAME SUFFIX       ===>     (For multiple plans in the same day)

   OVERRIDE DAILY PLAN    ===> NO         (YES / NO)                   

  ODATE              ===> 060601                                       


 Please fill in the Plan Name and press ENTER                          


   MASTER SCHEDULING LIB  ===> CTMP.PROD.SCHEDULE
   DAILY SCHEDULING LIB   ===> CTMP.PROD.SCHD
   MASTER PLANS LIB       ===> CTMP.PROD.PLANMSTR
   DAILY PROMPT PLANS LIB ===> CTMP.PROD.PLAN
   MASTER JCL LIB         ===> CTMP.PROD.JCLPROMP
   DAILY JCL LIB          ===> CTMP.PROD.JCLP

ENTER  END  COMMAND OR  PF3  TO TERMINATE

Table 263 The FETCH A PLAN Screen: Parameters

CTMEXEC CLIST

When CLIST CTMEXEC is activated, the EXEC / ORDER A PLAN screen is displayed:

Figure 381 The EXEC / ORDER A PLAN Screen

---- CONTROL-M - P.P.F. ---- EXEC / ORDER A PLAN -------------------------(P.3)
COMMAND ===>                                                               
                                                                           
   PLAN NAME              ===> REPTS      (Blank for plan selection list)  
                                                                           
   PLAN NAME SUFFIX       ===>            (For multiple plans in the same day)
                                                                           
   REMAINING PARAMETERS   ===> NO         (YES / NO)                       
                                                                           
   ODATE                  ===> 080800                                      
                                                                           
   FORCED FROM TIME       ===>                                             
                                                                           
                                                                           
 Please fill in the Plan Name (or blanks) and press ENTER                  
                                                                           
                                                                           
   DAILY  SCHEDULING LIB   ===> CTM.PROD.SCHD                              
   USER PROMPT PLANS LIB  ===>  CTM.PROD.PLAN                              
   DAILY PARAMETERS  LIB   ===> CTM.PROD.AEDI                              
                                                                           
                                                                           
 ENTER  END  COMMAND OR  PF3  TO TERMINATE                                 

Table 264 The EXEC / ORDER A PLAN Screen: Parameters

Usage Notes

• The PLAN NAME can be up to six characters in length. Use of the SUFFIX parameter in the FETCH phase permits creation of multiple Daily User Prompting Plans based on one Master Prompting Plan. This also makes it possible to duplicate (by overriding) a fetch of the same plan by setting the OVERRIDE DAILY PLAN parameter to YES on the FETCH A PLAN screen.

• Each job defined in the Master Scheduling table must contain an IN prerequisite condition in the format:

  Copy

  RUN-%%PLANID

  This prerequisite condition is added during the EXEC phase only after all parameters for a specific plan are assigned in the EXEC phase. %%PLANID resolves to the PLAN NAME (and SUFFIX) designated in the FETCH phase.

  Since each plan can be ordered multiple times for the same scheduling date, it is highly recommended to distinguish between the dependencies of the jobs in the plan based on PLAN NAME. Every prerequisite condition used for inter-plan dependency must contain the string %%PLANID. It is automatically replaced by the PLANID during the FETCH phase.

• The JCL of each job must be modified as follows:

  The first AutoEdit control statement must point to an AutoEdit Parameters library and the PLANID member. The PLANID member contains the unique PLANID of the job (automatically handled by Control-M).

  Copy

  %%LIBSYM CTM.PROD.SYMBOLS %%MEMSYM PLANID

  The second AutoEdit control statement must point to the Daily AutoEdit Parameters library and the member %%PLANID. Control-M automatically resolves %%PLANID to the PLAN NAME designated in the FETCH phase.

  The Daily AutoEdit Parameter library must be suffixed by a date parameter that is resolved by Control-M.

  Copy

  %%LIBSYM CTM.PROD.AEDI%%OMONTH.%%ODAY %%MEMSYM %%PLANID

• The %%PLANID member of each plan (in the Daily AutoEdit Parameter library) contains up to four configuration tables identified by AutoEdit variables.

  Parameters and data that are repeatedly used in a data processing environment can be defined in such a configuration table.

  A configuration table is a member of the GLOBAL library, which is referenced by the DAGLOBAL DDstatement. Such a member contains a set of user-defined local variables and their assigned values that can be referenced in the JCL of individual jobs.

  An AutoEdit variable identifies such a configuration table by a statement in the form %%CONFn=config_tablename in the %%PLANID member.

  Copy

  %%CONF1=INDICES
  %%CONF2=WEEKCHAR
  %%CONF3=
  %%CONF4=

  To use the configuration tables parameters procedure, insert the following AutoEdit statement in the JCL of each job:

  Copy

  //* %%INCLIB CTM.PROD.PARM %%INCMEM PPF2CONF

  The PPF2CONF member uses the configuration table values specified in the %%PLANID member to select the GLOBAL autoedit members to be included in the JCL of the job. It contains the following AutoEdit code:

  Copy

  %%IF *%%CONF1 NE *
  %%GLOBAL %%CONF1    
  %%ENDIF             
  %%IF *%%CONF2 NE *
  %%GLOBAL %%CONF2    
  %%ENDIF             
  %%IF *%%CONF3 NE *
  %%GLOBAL %%CONF3    
  %%ENDIF             
  %%IF *%%CONF4 NE *
  %%GLOBAL %%CONF4    
  %%ENDIF            

• The MEMLIB parameter of each job scheduling definition in the table must point to the Daily JCL library. The library name is suffixed by the AutoEdit date variables.

  Copy

  CTM.PROD.JCLP%%OMONTH.%%ODAY

• Occurrence numbering:

  It is recommended that all AutoEdit parameter names of jobs in the same plan be unique. In some plans, duplicate names may be unavoidable, and more than one job may share the same AutoEdit parameter name. If the parameters are to be assigned different values, that is, used for different purposes, each parameter must be assigned a different OCCUR NO during definition of the Master Prompting Plan.

  A %%SET statement specifying the OCCUR NO. must be included in the JCL of the associated jobs as follows:

  Copy

  %%SET %%OC# = 01

  When the AutoEdit parameter member is created, each AutoEdit parameter includes the OCCUR NO. as a suffix.

• Using the Parameter Prompting Facility: Type 2 requires customizing the Control-M submit exit (CTMX002). This exit does the following:

  • It ensures that at the time when the job is submitted, the AutoEdit Parameters library contains the PLANID member.

  • It places in the PLANID member an AutoEdit variable definition in the form

    Copy

    %%PLANID=plan_id

    in order to provide the job with a unique identity (plan_id). This is done using an OUT condition in the job scheduling definition, as described in the source code of the exit.

  For information about modifying the exit, see the CTMX2PPF member in the IOA SAMPEXIT library.

Maintenance Utilities

The following jobs are located in the Control-M JCL library.

PPF2DEL

This job can be run to delete sets of daily libraries according to specified date criteria.

Figure 382 PPF2DEL Utility Screen

//PPF2DEL JOB  ACCNT,CTM,CLASS=A
//*
//*  THIS JOB DELETES SETS OF DAILY LIBRARIES CREATED 3,4,and 5
//*  DAYS PRIOR TO THE CURRENT DATE (%%ODATE).
//*
//*************************************************************
  %%SET %%DT3 = %%CALCDATE %%ODATE - 3
  %%SET %%DELDATE3 = %%SUBSTR %%DT3 3 4
  %%SET %%DT4 = %%CALCDATE %%ODATE - 4
  %%SET %%DELDATE4 = %%SUBSTR %%DT4 3 4 
  %%SET %%DT5 = %%CALCDATE %%ODATE - 5
  %%SET %%DELDATE5 = %%SUBSTR %%DT5 3 4 
//DELLIB   EXEC PGM=IDCAMS
//SYSPRINT DD   SYSOUT=*
//SYSIN    DD   *
  DELETE CTM.PROD.PLAN%%DELDATE3
  DELETE CTM.PROD.SCHD%%DELDATE3
  DELETE CTM.PROD.JCLP%%DELDATE3
  DELETE CTM.PROD.AEDI%%DELDATE3
  DELETE CTM.PROD.PLAN%%DELDATE4 
  DELETE CTM.PROD.SCHD%%DELDATE4 
  DELETE CTM.PROD.JCLP%%DELDATE4        
  DELETE CTM.PROD.AEDI%%DELDATE4              
  DELETE CTM.PROD.PLAN%%DELDATE5   
  DELETE CTM.PROD.SCHD%%DELDATE5      
  DELETE CTM.PROD.JCLP%%DELDATE5   
  DELETE CTM.PROD.AEDI%%DELDATE5
//

PPF2DAY

This job allocates the daily libraries that are to be used by the Parameter Prompting Facility: Type 2. It also copies the required jobs from the Master JCL library to the Daily JCL library.

These are time consuming tasks normally performed as part of the FETCH and EXEC phases of the Online facility. By scheduling this job daily under Control-M, the time required to execute the FETCH and EXEC phases is reduced.