Defining Restart in the Job Scheduling Definition

1. Enter the IOA Online Facility and open a job scheduling definition for job IDJOB5.
2. Ensure that the following values are part of the job scheduling definition:
   • In the MEMNAME field, specify IDJOB5. Fill in the appropriate JCL library name in the MEMLIB field.
   • In the GROUP field, specify IDGRP3.
   • In the DESC field, specify RESTART JOB UNDER CTM/RESTART.
   • In the DAYS field, specify ALL, and specify Y in all the MONTHS fields. These are the only Basic Scheduling parameters you should define.
   • Do not defined any Runtime Scheduling parameters.
   • In the OUT fields, define the condition

     IDJOB5-ENDED-OK   ODAT    +

   You are now ready to define the ON and DO statements. These will include your restart parameters.

3. In the ON block, specify ANYSTEP as the program step (PGMST) value. Specify >C0004 as the codes value.

   The meaning of the >C0004 value should be clear. Generally, a step is considered to have ended OK if the routine returns a code of C0004 or lower. Therefore, a CODES value of >C0004 instructs Control-M to perform the accompanying DO statements if the job ended NOTOK.

   In the preceding chapter, and again in this step, you specified ANYSTEP as the PGMST step values. These ON step values should be examined more closely.

   ON Steps

   The ON step fields identify the possible steps against which Control-M will check for the specified CODES values.

   Two types of step values can be specified:

   • Program Step (PGMST) value
   • Procedure Step (PROCST) value

   You can specify either or both types of values, but you must specify at least one value if you use an ON block.

   Valid step values can be any of the following:

   • Literal value (for example, S3, if this is a step name)
   • Keyword value that represents a step

     Valid keyword values are

     • ANYSTEP, which is valid only as a PGMST value

       DO statements are performed if the CODES criteria are satisfied for any program step.

     • +EVERY

       DO statements are performed only if the CODES criteria are satisfied for all steps, program and/or procedure, depending on the definition.

   • Step Range Name, which is valid only for a PGMST value

     You can define a range of steps in the STEP RANGE statement, immediately above the ON statement. You must assign a name to this step range.

     You can then specify this step range name, preceded by an asterisk, as the step value in the ON statement. The asterisk prefix in the ON statement instructs Control-M to check the program step range defined in the STEP RANGE field, rather than looking for an actual program step by that name.

     DO statements are performed if the CODES criteria are satisfied for any program step in the step range.

4. Define the following DO COND statement as the first DO statement in the ON block:

   IDJOB5-END-NOTOK   ODAT   +

   You can now to define a Shout statement to the operator. However, because this is only an exercise and you do not want the shout to actually go to the operator, you will instead send the shout to yourself.

5. Define a DO SHOUT statement as the next DO statement in the ON block. The target location, or TO value, defaults to your user ID. Specify the message:

   IDJOB5 RUN FAILED. CORRECT PROBLEM AND CONFIRM RESTART.

   You are now ready to define your restart parameters. Two statements are generally used in combination, to define a restart:

   • DO IFRERUN
   • DO RERUN

   The DO IFRERUN statement is used to indicate that a restart is desired. It defines parameters to be used for restart, such as FROM step and TO step. This statement tells Control-M that if the job is rerun, hence the name DO IFRERUN, it should be rerun in accordance with the restart values specified in the DO IFRERUN statement.

   The DO RERUN parameter merely instructs Control-M to run the job again. If you wanted a rerun without a restart, you would specify only the DO RERUN parameter, and the job would be rerun from the beginning.

   The DO IFRERUN statement precedes the DO RERUN statement.

6. Enter IFRERUN in the blank DO statement. The DO IFRERUN statement is opened.

   Note that this statement contains FROM, TO, and CONFIRM fields. The default value of the CONFIRM field should be N (No).

7. Set the CONFIRM value to Y (Yes).

   Note: The CONFIRM field of the DO IFRERUN statement is similar in meaning to the CONFIRM runtime scheduling parameter that you used in Chapter 1, "Introduction to Control-M." However, it applies only to restarted jobs, whereas the CONFIRM runtime scheduling parameter applies to all job runs.

   You can now take a look at the FROM and TO fields.

   The FROM field indicates the step from which the restart should begin, and the TO field indicates the step to which the restart should continue.

   Both the FROM and the TO fields allow specification of a program step, to the left of the period, and/or a procedure step, to the right of the period. You can specify either or both values.

   • A TO step value can only be a literal value, such as S3, if this is a step name, or blank. If no TO value is specified, job processing continues to the end.
   • The FROM field allows specification of either a literal value or a keyword that represents a step. Some of the valid keyword values for the FROM step are listed in the following table:

   Table 9 DO IFRERUN: Selected FROM Keyword values

   Keyword	Description
   $FIRST	First step of the job.
   $ABEND	Step of the job that ended NOTOK due to system abend, user abend, condition code C2000 (PL/1 abend), or JFAIL (job failed on JCL error). $ABEND is a subset of $EXERR, described below.
   $FIRST.$ABEND	First step of the abended procedure.
   $EXERR	Job step that ended with any error, including an abend, or that ended with a condition code that is redefined using the ON and DO statements, as ENDED NOTOK

8. Specify $EXERR in the FROM field.
9. Enter RERUN in the blank DO statement. This statement has no subparameter values.

   Before exiting the job scheduling definition, return and define one more OUT condition.

10. In the OUT condition line, add the following condition as the second condition on that line:

    IDJOB5-END-NOTOK   ODAT   -

    If the job fails, and then successfully finishes following restart, this OUT condition deletes the DO COND condition that was added by the job failure. If the job does not fail, there is no IDJOB5-END-NOTOK condition to delete. In this case, no deletion occurs and processing continues.

    Your job scheduling definition appears as shown in Job Scheduling Definition Figures.

11. Exit the Job Scheduling Definition screen to the Job List screen.
12. Exit the Job List screen and save the changes, by entering Y in SAVE field of the Exit Option window. The Table List screen is displayed.
13. Reenter the Job List screen for the table, and order job IDJOB5. The Job Order Messages screen is displayed. and the job is ordered.
14. Exit the Job Order Messages screen and display the Active Environment screen by entering =3 in the COMMAND field. The Active Environment screen is displayed.
15. Ensure that filter IDGS is displayed. If it does not appear in the Filter field, enter SHOW IDGS in the COMMAND field).
16. Refresh the display as often as needed. A message similar to the following message is Shouted to your terminal:

    CTM- IDJOB5 RUN FAILED. CORRECT PROBLEM AND RESTART  02.02 12:38 CN(INTERNAL)

    The job goes through a process of submission and execution, and finally ends with the status: Ended- Not "OK" Due to CC - Rerun Needed:

    The Active Environment screen appears as follows Job Scheduling Definition Figures. If the jobs from the exercises in the preceding chapter have not been deleted by site maintenance, they will also appear in the screen.

    Filter: IDGS      ------- Control-M  Active  Environment ------ UP    <D> - (3)

    COMMAND ===>                                                    SCROLL ==> CRSR

    O Name     Owner    Odate  Jobname  JobID   Typ ----------- Status ------------

      IDJOB5   ID       020201 M21     /29162   JOB Ended- Not "OK" Due to CC -

                                                    Rerun Needed              

    ========= >>>>>>>>>>>>>        Bottom of Jobs List       <<<<<<<<<<<<< ========

    The CC in the status refers to a condition code. You can now review the job log and identify the condition code problem.

17. Call up the log for the job by entering L in the OPTION field. The Control-M Log screen is displayed for the job Job Scheduling Definition Figures.

    Each event in the life cycle of the job appears as a message issued by Control-M. Note the following messages:

    • SEL216W identifies a problem: An unexplained condition code of 0008 in step S3, reflecting what you deliberately defined in the job.
    • SEL214I indicates that rerun is needed, reflecting what you deliberately defined in the job.
    • SEL219I indicates that the job ended "NOT OK"