Previous Topic: 4.3 Operations Reference

Next Topic: 4.3.2 Implementing the Processing Schedule

4.3.1 Processing Schedule


A processing schedule is a set of rules used to determine
which operational jobs should occur on any given day.  Use of
a processing schedule helps to ensure that the appropriate
CA MICS jobs run in a predetermined order.

CA MICS creates and maintains a processing schedule based on
the specifications coded during CA MICS installation.
Scheduling control parameters include the following:

o  The CA MICS calendar specified with the 13MONTHYEAR
   statement in sharedprefix.MICS.PARMS(CPLXDEF) or
   prefix.MICS.PARMS(SITE)

o  Backup frequency specified in prefix.MICS.PARMS(JCLDEF)

o  Whether WEEKLY, MONTHLY, and/or YEARLY processing can
   occur during weekends specified in
   prefix.MICS.PARMS(EXECDEF)

The following table summarizes the standard CA MICS
scheduling algorithm--when each job should be executed and
what job needs to successfully complete prior to the job in
question:

+---------+--------------------------------------+----------+
| Opera-  |                                      |          |
| tional  |                                      |  Job's   |
| Job     | When should it be run?               |Dependency|
+---------+--------------------------------------+----------+
| SPLITSMF| One or more times per day when input | Previous |
|         |     data is available (Optional)     |   INCRccc|
| INCRccc | One or more times per day when input | Previous |
|         |     data is available                |   INCRccc|
|         |                                      |   or     |
|         |                                      |   DAILY  |
| DAILY   | Each day when input data is available| Previous |
|         |                                      |   DAILY  |
|         |                                      |   or     |
|         |                                      |   INCRccc|
| WEEKLY  | Two days after end of week (Monday)  | DAILY    |
| MONTHLY | Three days after end of month        | DAILY    |
| YEARLY  | Five days after end of year          | MONTHLY  |
| BACKUP  | After each day's complete updating   |          |
|         |       activity                       | NONE     |
+---------+--------------------------------------+----------+

 Figure 4-1.  Job Scheduling and Dependencies

NOTE:  The CA MICS scheduling algorithm does not include the
       optional AUDIT, HISTW, and HISTM operational jobs for
       weekly/monthly archive tape processing.

o  For Archive Audit processing:

     -  If you specified
             ARCHIVE AUDIT YES JOB AUTOSUBMIT
        in prefix.MICS.PARMS(JCLDEF), CA MICS automatically
        submits the AUDIT job during weekly processing.

     -  If you specified
             ARCHIVE AUDIT YES JOB
        in prefix.MICS.PARMS(JCLDEF) without the optional
        AUTOSUBMIT parameter, you must schedule the AUDIT job
        separately.

     -  If you specified
             ARCHIVE AUDIT YES STEP
        in prefix.MICS.PARMS(JCLDEF) or accepted the  default
        (STEP), then Archive Audit processing occurs within
        the WEEKLY job WEEK300 step.

     -  If you specified
             ARCHIVE AUDIT NO
        in prefix.MICS.PARMS(JCLDEF), then Archive Audit
        processing is bypassed.

o  For Archive Weekly History processing:

     -  If you specified
             ARCHIVE HISTW YES JOB AUTOSUBMIT
        in prefix.MICS.PARMS(JCLDEF), CA MICS automatically
        submits the HISTW job during weekly processing.

     -  If you specified
             ARCHIVE HISTW YES JOB
        in prefix.MICS.PARMS(JCLDEF) without the optional
        AUTOSUBMIT parameter, you must schedule the HISTW job
        separately.

     -  If you specified
             ARCHIVE HISTW YES STEP
        in prefix.MICS.PARMS(JCLDEF) or accepted the default
        (STEP), then Archive Weekly History processing occurs
        within the WEEKLY job WEEK300 step.

     -  If you specified
             ARCHIVE HISTW NO
        in prefix.MICS.PARMS(JCLDEF), then Archive Weekly
        History processing is bypassed.

o  For Archive Monthly History processing:

     -  If you specified
             ARCHIVE HISTM YES JOB AUTOSUBMIT
        in prefix.MICS.PARMS(JCLDEF), CA MICS automatically
        submits the HISTM job during monthly processing.

     -  If you specified
             ARCHIVE HISTM YES JOB
        in prefix.MICS.PARMS(JCLDEF) without the optional
        AUTOSUBMIT parameter, you must schedule the HISTM job
        separately.

     -  If you specified
             ARCHIVE HISTM YES STEP
        in prefix.MICS.PARMS(JCLDEF) or accepted the default
        (STEP), then Archive Monthly History processing
        occurs within the MONTHLY job MONTH300 step.

     -  If you specified
             ARCHIVE HISTM NO
        in prefix.MICS.PARMS(JCLDEF), then Archive Monthly
        History processing is bypassed.

NOTE:  The CA MICS scheduling algorithm does not include the
       DAILYRPT, WEEKRPT, and MONTHRPT operational jobs for
       daily/weekly/monthly MICF production reporting.

o  If you specified
        AUTOSUBMIT YES
   in prefix.MICS.PARMS(JCLDEF), CA MICS automatically
   submits the DAILYRPT, WEEKRPT, and MONTHRPT jobs during
   daily/weekly/monthly processing.

o  If you specified
        AUTOSUBMIT NO
   in prefix.MICS.PARMS(JCLDEF), you must schedule the
   DAILYRPT, WEEKRPT, and MONTHRPT jobs separately.

CA MICS provides two automated processes to implement the
processing schedule.

o  Operational Status and Tracking SCHEDULE command

o  The SCHEDULE job--see prefix.MICS.CNTL(SCHEDULE)

NOTE:  Neither Operational Status and Tracking nor the
       SCHEDULE job support incremental update.  You must
       schedule the SPLITSMF (if used) and INCRccc jobs
       either manually or using your installation's
       production batch job scheduling facility.

Both the SCHEDULE command and the SCHEDULE batch job build a
tailored job stream for each unit database using the
following rules:

o  Start the job stream by copying the DAILY job into today's
   job stream.

   DAILY should be run as soon as practical after input data
   becomes available and after all cccINCR jobs (if any) in
   this unit complete successfully.  This is normally done
   after midnight for the day's activity that is being
   processed.  Most organizations schedule the DAILY to
   complete before the start of prime shift so that the
   reports for yesterday's activity are ready for review and
   the database is current.

   If a restart is required, the DAILY job must successfully
   complete before the start of the next scheduled update.

   NOTE:  When an operational job does not successfully
          complete, the database is marked non-updatable.
          Consequently, succeeding DAILY, WEEKLY, MONTHLY, or
          YEARLY jobs will not be processed until the
          abnormally terminated jobs are successfully
          completed.

   For jobs using SMF data as an input source, the
   SUSPENDLIMIT keyword in prefix.MICS.PARMS(SMFOPS)
   determines how long to retain data for jobs that are still
   in process (for example, jobs waiting to be printed or in
   the system when it failed).  During each day's processing,
   CA MICS merges suspended data with the new data in an
   attempt to complete suspended jobs' data.  The
   SUSPENDLIMIT keyword sets the maximum number of days for
   which CA MICS retains job level data for the matching
   attempt.  For more information on SUSPENDLIMIT, see
   section 7.3.1.16 of the Batch and Operations Guide.

  o  SCHEDULE also prohibits a WEEKLY, MONTHLY, or YEARLY
     from running in combination with one another.

  o  If a WEEKLY is due and one day has elapsed since it
     became due, copy the WEEKLY JCL into today's job stream.
     To determine if a WEEKLY is due, SCHEDULE computes the
     week start using the day of the week (keyword WEEKSTART)
     specified in prefix.MICS.PARMS(SITE).  By default, the
     week starts on Sunday.

   For an organization operating 7 days a week, WEEKLY should
   be executed following completion of the DAILY between 0:00
   and 8:00 on Monday.  This makes the weekly reports (for
   the previous week's activity) available by the beginning
   of prime shift on Monday.

  o  If a MONTHLY is due, three days have elapsed since it
     became due, and a WEEKLY has not already been scheduled,
     copy the MONTHLY job into today's job stream.

   For an organization running a twelve month year, MONTHLY
   should be executed following completion of the DAILY
   between 0:00 and 8:00 on the 3rd day of the month.

   o If a YEARLY is due, five days have elapsed since it
     became due, and a WEEKLY or MONTHLY has not already been
     scheduled, copy the YEARLY JCL into today's job stream.

   For an organization running a standard month (30 or 31
   days, except for February), YEARLY should be executed
   following completion of the DAILY run after the 5th day of
   the new year.  This makes the yearly reports available in
   a timely fashion for the previous year's activity.

   o  SCHEDULE will not schedule a WEEKLY, MONTHLY, and
      YEARLY on the same day.  If any combination of these
      jobs are due to be scheduled on the same day, SCHEDULE
      will schedule the lesser job.  For example, if a
      MONTHLY and YEARLY are due at the same time, the
      MONTHLY job will be scheduled.

   o  If a BACKUP is required because one of the following
      statements is true, then copy the BACKUP job into
      today's job stream.

      -  the backup frequency specified in
         prefix.MICS.PARMS(JCLDEF) has been reached

      -  a WEEKLY job has been scheduled

      -  a MONTHLY job has been scheduled

      -  a YEARLY job has been scheduled

   It is important to include BACKUP in each day's process
   because if the CA MICS database becomes damaged, the
   entire database can be restored without reprocessing raw
   data.

   o  Save today's job stream in the Schedule Restart File in
      prefix.MICS.RESTART.CNTL.

   o  Submit the generated job stream (SCHEDULE command) or
      write the job stream to the internal reader (SCHEDULE
      job--the internal reader will submit the job for
      execution).

   ******************** IMPORTANT NOTICE ********************
   * If your installation uses the Thirteen Month Fiscal    *
   * Year Option or another special CA MICS                 *
   * calendar, the WEEKLY, MONTHLY, and YEARLY              *
   * jobs are run after the user-defined week,              *
   * month, and year ends and are not tied to the           *
   * standard calendar week, month, and year.               *
   *                                                        *
   * You can review the processing scheduled for today and  *
   * the next few days through the Operational Status and   *
   * Tracking displays.                                     *
   *                                                        *
   * You can build a job stream for today's scheduled       *
   * processing without submitting the job for execution.   *
   *                                                        *
   *  o  With Operational Status and Tracking,              *
   *                                                        *
   *     -  Enter the SCHEDULE command with the EDIT        *
   *        operand.  Operational Status and Tracking will  *
   *        display the generated batch job stream under    *
   *        PDF Edit.                                       *
   *                                                        *
   *     -  You can save the generated job stream in the    *
   *        Schedule Restart File by entering END on the    *
   *        PDF Edit display.  Enter CANCEL to exit         *
   *        without saving the generated job stream.        *
   *                                                        *
   *  o  With the SCHEDULE job (prefix.MICS.CNTL(SCHEDULE)),*
   *                                                        *
   *     -  Specify NOSUBMIT on the SCHEDULE job's EXEC     *
   *        statement as follows:                           *
   *                                                        *
   *          //SCHEDULE EXEC MICSNDB,SYSPARM='NOSUBMIT'    *
   *                                                        *
   *     -  The generated job will be saved in the Schedule *
   *        Restart File (prefix.MICS.RESTART.CNTL).        *
   *                                                        *
   **********************************************************

SCHEDULE DELAY

To determine when a WEEKLY, MONTHLY, or YEARLY job needs to
be run, SCHEDULE uses today's date and the date the last
WEEKLY, MONTHLY, and/or YEARLY job successfully completed.
SCHEDULE determines if a period has changed (i.e., from one
calendar week, month, or year to the next) and if the
required job's delay has expired.  It then constructs the JCL
for the appropriate processes for execution in today's job
stream.

The table at the beginning of this section summarizes the
weekly, monthly, and yearly schedule delays.  The schedule
delay causes the job to be scheduled n number of days after
its calendar scheduling date so that WEEKLY executes one day
after the beginning of the week (on Monday for the default
WEEKSTART specification), MONTHLY on the third day of the
month, and YEARLY on the fifth day of the new year (on
January 5th for the standard calendar year).

You can change the delay in scheduling the WEEKLY, MONTHLY,
or YEARLY with a local modification that changes the
variables WKDELAY, MNDELAY, and YRDELAY.

o  Make a local modification to
   sharedprefix.MICS.SOURCE(SCHEDULE) for the SCHEDULE batch
   job.

o  Make a local modification to
   sharedprefix.MICS.SOURCE(MAFOSCHD) for the Operational
   Status and Tracking SCHEDULE command.  This change will be
   effective until after the next DAILY, WEEKLY, or MONTHLY
   job completes successfully.

Follow the instructions in the user modifications section of
the CA MICS System Modification Guide (SMG) to implement
changes to sharedprefix.MICS.SOURCE members.