Docstoc

Ca7 standards

Document Sample
Ca7 standards Powered By Docstoc
					                                                                                               Page 1

                        ISL/OPS/A018 - CA-7 Product Standards and Scheduling Techniques




8. Scheduling standards and techniques

8.1. CA-7 Schedule IDS

8.1.1. Non-calendar scheduled jobs
The following Schedule IDs are to be used for jobs and suites which are brought onto CA-7 other
than by being scheduled.

       SCHID     DESCRIPTION
       001       Manually DEMANDed where no other SCHID is applicable
       003       Online initiated by an application ( eg. via CICS, etc. )
       004       Initiated by Front-End system
       005       Second pass of online initiated or Front-End job




8.1.2. Externally tracked jobs

The following SCHID will be used by jobs which are submitted outside of CA7 and Externally
Tracked.

       SCHID DESCRIPTION
       10    Externally Tracked Jobs



8.1.3. `Specific Day' jobs

The following Schedule IDs are for jobs which run every "day" of their calendar, e.g. jobs which
run every Working Day Monday; or jobs which run every Bank Holiday Friday.

       SCHID      DESCRIPTION
       011        Every Monday
       012        Every Tuesday
       013        Every Wednesday
       014        Every Thursday
       015        Every Friday
       016        Every Saturday
       017        Every Sunday
                                                                                                          Page 2
8.1.4. Self-triggering / Multiple run jobs
The following Schedule IDs will be used by jobs which need to run more than once per day, and where each
run requires a different Schedule ID.
For jobs which run more than once per day, but do not need a different Schedule ID, the original Schedule
ID should be used for each run, e.g. SCHID=11 for all of the runs on Monday.




        SCHID          DESCRIPTION
        020 to 064     Self-Triggering / Multiple run per day




8.1.5. Symetric schedules
The following Schedule IDs will be used by jobs which need to have a symetric schedule.


        SCHID          DESCRIPTION
        065 to 069     Symetric Schedules




8.1.6. OMS Schedule IDs
The following Schedule IDs will be exclusively used by the OMS Billing suite :


        SCHID          DESCRIPTION
        081 to 096     OMS Billing Suite




8.1.7. Ad hoc triggered suites
The following Schedule IDs will be used by suites which only ever run on an ad hoc basis. Individual ad
hoc jobs do not need to use this Schedule ID.


        SCHID        DESCRIPTION
        97 to 99     Adhoc Suites



8.1.8. Dataset triggered jobs
The following Schedule IDs will be used by jobs which are dataset triggered.


        SCHID        DESCRIPTION
        100          Dataset Triggers
                                                                                               Page 3
8.1.9. `Specific Working Day' jobs
The following Schedule IDs will be used only by those jobs resolved against the Working Day
Only calendar :




       SCHID         ][DESCRIPTION
       101           1 st working day of each month
       102 to 123    2nd working day of each month etc. through to 23rd
                     working day of each month (max.)
       129           Last working day of each month
       130           Every working day




8.1.10. `Specific Day of Month' jobs
The following Schedule IDs will be used only by those jobs resolved against the Every Day or
Working Day Only calendars :


       SCHID     SECOND DIGIT          THIRD DIGIT
       1xy       x = Day               y = week in the month
                 3 = Monday            1 = 1 st week
                 4 = Tuesday           2 = 2nd week
                 5 = Wednesday         3 = 3rd week
                 6 = Thursday          4 = 4th week
                 7 = Friday            5 = 5th week
                 8 = Saturday          6 = Last week -3
                 9 = Sunday            7 = Last week -2
                                       8-= Last week -1
                                       9 = Last week




 8.1.11. `Specific Dates of the Month' jobs
The following Schedule IDs must be used only by those job resolved against the Every Day
calendar :
                                                                                                         Page 4


        SCHID         [DESCRIPTION
        201 to 231    1 st of the Month through to 31 st of the Month
        232 to 239    Last of the month -7 through to Last of the month




8.1.12. Bank Holiday jobs
For jobs which are required to run on Bank Holidays, the following Schedule IDs are available if required. For
example a job may be part of a Monday suite, yet need to run "stand alone" on Bank Holiday Mondays. If it
were triggered with SCHID=11, it would trigger the rest of the suite.
Use existing SCHIDs where possible.




        SCHID          DESCRIPTION
        240 to 244     Bank Holidays



8.1.13. Quarterly / Annual jobs
The following Schedule IDs are used as follows


        SCHID          DESCRIPTION
        200            Half-yearly - second Monday of January and July
        245 to 249     Annual Jobs
        250            Quarterly - last day of months.: 3, 6, 9, 12
        251            Quarterly - first Saturday of months : 1, 4, 7, 10
        252            Quarterly - first Sunday of months : 1, 4, 7, 10
        253            Quarterly - second Friday of months : 2, 5, 8, 11
        254            Quarterly - third Saturday of months : 3, 6, 9, 12
        255            Quarterly - third Friday of months : 3, 6, 9, 12




8.1.14. Reserved Schedule IDs
The following Schedule IDs are reserved for future use, and their issue should be requested via the CSO Operate
MVS Scheduling Team:
                                                                                                  Page 5


      SCHID        DESCRIPTION
      002          Reserved
      006 to 009   FReserved
                   Reserved
      019          Reserved
      070 to 80    Reserved
      124 to 128   Reserved




8.2. Scheduled headers
8.2.1. Schedule calendars
 Note: See section 6.1.2.2 Calendar Initialisation Parameters for further
         details
The following calendars are available:




       ED     Every Day
       WO     Working days Only
       BH     Bank Holidays only
       IN     Index




  1. When calendars are defined, holidays which fall on Saturdays and Sundays must not be
     defined as NOSCHDDAYS.
  2. Any additional calendars must have a unique first letter to comply with the standard for schedule
     header jobs, and their use must be agreed with the CSO Operate MVS Scheduling Team, who
     will liaise with MVS Production Control North who will supply the calendar.
8.2.2. Scheduled headers
All scheduled header jobs must have a #NOX card in the JCL
8.2.3. `Simple Scheduled' headers
The jobname format of all scheduled header jobs (except for Complex and Symetric scheduled
headers - see below), will be as follows :
       rxxxhhmz where :
         . r = the roll
            parameter:
               N - do not roll on non-schedule days
                                                                                                              Page 6
                  D - do not run on non-schedule days
                  F - roll forward on non-schedule days
                  B - roll backward on non-schedule days
             . xxx = SCHID
             . hhm = time of day for submission ( missing last digit of minutes)
             . z = first character of the calendar e.g. E for ED or B for BH
For example
       N011220E
means this job will run at 2200 every Monday including Bank Holidays, and has been resolved against the
ED calendar.
8.2.4. `Complex Schedule' headers
It is intended that any scheduled header will only have one Schedule ID, and that its processing
requirements can be met by the Schedule ID standards, and its jobname will conform to the
`Simple-Schedule' jobname format.
If a jobs processing requirements cannot be met by the Schedule ID standards a different scheduled
header format needs to be used:
         rxxxhhmz where :
           . r = the roll parameter:
                       . N.- do not roll on non-schedule days
                       . D - do not run on non-schedule days
                       . F - roll forward on non-schedule days
                       . B - roll backward on non-schedule days
           . xxx = meaningful "freeform" descriptive
           . hhm = time of day for submission (missing last digit of minutes)
           . z = first character of the calendar e.g. E for ED or B for BH

The jobname, and a brief descriptive of its processing day/s must be specified on the schedule diagrams.

An example of a complex header would be NNLD235E, which has 7 SCHIDs, 11-17. However as its
processing criteria is :- every Monday unless it is the last day of the month; every Tuesday unless it is the last day
of the month; every Wednesday unless it is the last day of the month; etc., existing Schedule IDs could not be
used.

8.2.5. `Symetric' headers

The use of Symetric schedules should be kept to an absolute minimum, but where symetric scheduling is
necessary, the job should use a schedule id reserved for symetric schedules (65-69), and its job name should
conform to the following format

       rxxShhmz where:
         . r = the roll parameter:
            . N - do not roll on non-schedule days
                                                                                                 Page 7
        . D - do not run on non-schedule days
        . F - roll forward on non-schedule days
        . B - roll backward on non-schedule days
     . xx = meaningful "freeform" descriptive
     . S = denotes Symetric schedule
     . hhm = time of day for submission (missing last digit of minutes)
     . z = first character of the calendar e.g. E for ED or B for BH
The jobname, and a brief description of its processing day(s) must be included in the
schedule diagrams.
An example of a symetric header would be N35S210E, which runs every 35 days at
21:00.
 8.2.6. Second Level headers
Scheduled headers can trigger a mixture of application suites, housekeeping suites, and
individual jobs, and inserting separate second level headers below the scheduled header to
trigger individual suites, allows the associated batch to be easily Held, Cancelled or Not
Triggered.
 For example CSS batch may need to be held until a software release has been installed, but
 the housekeeping batch could continue to process.
 The standard used for the second level
 header is :
        snnrhhmz
        where :
    . s = meaningful letter corresponding to the application (e.g. H for housekeeping)
     . nn = day of week e.g. SU, MO, etc.
     . r = the roll parameter
        . N - do not roll on non-schedule days
        . D - do not run on non-schedule days .
        . F - roll forward on non-schedule days
        . B - roll backward on non-schedule days
     . hhm = time of day for submission (missing last digit of minutes)
     . z = first character of the calendar e.g. E for ED or B for BH

For
example
:

       CMON220E

would be a CSS header triggered by NO 11220E.

Second Level headers are not used for monthly, quarterly, yearly, complex, or symetric
headers.

8.2.7. Lower level headers

Further levels of headers below the Second Level headers, or after monthly, quarterly, yearly,
complex, or symetric headers, if required, should be a meaningful descriptive of the sub-suite
that is triggered, e.g.:

       RACFHKG
       BILLPROD
                                                                                             Page 8 0.


8.3. Scheduling techniques

Note: See Database Maintenance Guide for further details

8.3.1. General techniques

  1. Schedule header jobs using SCHIDs 011 to 017 must not be scheduled more often than
     once per hour.
     Jobs must never be scheduled using the DAILY facility.
     All schedules which could be defined to CA-7 (e.g. Day before Bank Holiday schedules;
     schedules which run during software upgrades) must be defined to CA-7, in order to reduce
     ad hoc scheduling requests
  4. The SCHDMOD command must only be used in emergency situations with full awareness that
     any use runs the risk of being overlaid by schedule resolution.
  5. The NXTCYC command must only be used for temporary, short term schedule manipulation.

  6. Any dataset triggers or dependencies used by automation must have a high level qualifier of
     AUTO.
  7. Negative dependencies or VRM must be used to avoid "waiting for dataset" conditions.
  8. INPUT/OUTPUT Networks must not be used
  9. User Requirements must be automatically posted

8.3.2. TRIGID's

   1. The initial SCHID should be propagated throughout the whole schedule.
   2. TRGIDs should only be used to convert SCHID 020 to 064 for self-triggering/multiple run
      jobs.
   3. SCHID 000 must not be used on triggers - a trigger definition must be defined for every
       SCHID for every run of the triggered job.

8.3.3. Batch and TRAILER terminals

There are circumstances where schedules need to be built or altered by batch or trailer terminals, for
example where schedule requirements are determined by information held outside CA-7. However
use of such scheduling techniques must be kept to a minimum, clearly documented on schedule
diagrams, and detailed in Job Procedures. Standard CA-7 scheduling methods must be employed
wherever possible.

8.3.4. LEADTM/SCHID for dependencies

   1. When defining job or dataset dependencies, LEADTM=99 or 00 should be used
  2. Where necessary, 01-98 may be used, but must be documented on the schedule diagram.
  3. SCHID=000 may be used when defining dependencies, only if the dependency is valid for
      every run of the job.

8.3.5. Queue pollution

   1. The scheduling of large amounts of jobs at anyone time should be avoided.
   2. All scheduling techniques used should avoid putting jobs onto queues before they are eligible
      to run. Where this cannot be avoided e.g. because a job has multiple dependencies,
n

                                                                                                          Page 9

       no job must be on a queue for more than 24 hours.
    3. Any command which stops the normal functioning of CA-7, such as STOP,Q= must not be used except
       in an emergency.
    4. The practice of putting "overnight" jobs onto the queues during the day to be run later (perhaps by
       opening a WLB class) should be avoided where possible.
8.3.6. Job time definitions
8.3.6.1. Scheduled
There are three times to be defined when a job schedule is defined :
  1.         SBTM -set to the earliest time that the job can start
  2.         LDTM - set this to 10 minutes
  3.         DOTM - set this to SBTM + 15
8.3.6.2. Triggered
There are four times to be considered when triggering a job, whether from another job or by a dataset:
    1. DOTM - this should be left to be calculated by CA-7 at queue entry time as - current time + QTM (queue
        time) + CLOCK-TIME (expected/average run time) + 5 minutes.
            . This value should only be set if the job is to be used as a "deadline" for late processing
               purposes.
    2. QTM - this must be coded as 20 minutes except in the following circumstances :
            . When the triggered job has dependencies which will not normally be satisfied until after the job
               has entered the request queue, the QTM must be increased to allow for the expected time for
               these dependencies to be satisfied.
            . When the run time of the job is variable, the QTM must be set to the maximum variation (unless
               CLOCK-TIME=2359 on Job Definition screen - see LEADTM below). When jobs run in a
               special class, the QTM must be set to obtain the correct delay before execution.
            . When jobs require immediate Late Processing - set QTM=00.
    3. LEADTM - must be coded as 00 minutes except in the following circumstances :
            . When a job has an unreliable CLOCK-TIME, e.g. because it abends frequently, the LEADTM
               must be set to the maximum expected run time of the job, and the CLOCK-TIME on the Job
               Definition screen must be changed to 2359.
    4. SBTM - not used except in the following circumstances
            . When it is necessary for a job to have a submit time.
            . When the triggering job was not triggered using a QTM.
            . When there is a sequence of jobs which need to run several times per day, where one or more of
               the jobs must have a submit time.

If the use of SBTM is valid, then the Time parameters should be coded as follows:

    1. DOTM -must be coded, but must be greater than the DOTM of the triggering job.
    2. QTM - not coded
    3. LEADTM - not coded
    4. SBTM -optional - if coded will define the earliest run time for the job.

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:106
posted:5/30/2011
language:English
pages:9