Ca7 Standards

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 SCHID 001 003 004 005

DESCRIPTION Manually DEMANDed where no other SCHID is applicable Online initiated by an application ( eg. via CICS, etc. ) Initiated by Front-End system 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 011 012 013 014 015 016 017

DESCRIPTION Every Monday Every Tuesday Every Wednesday Every Thursday Every Friday Every Saturday 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 020 to 064

DESCRIPTION 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 065 to 069

DESCRIPTION Symetric Schedules

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

DESCRIPTION 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 97 to 99

DESCRIPTION Adhoc Suites

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

DESCRIPTION Dataset Triggers

Page 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 101 102 to 123 129 130

][DESCRIPTION 1 st working day of each month 2nd working day of each month etc. through to 23rd working day of each month (max.) Last working day of each month 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 1xy x = Day

THIRD DIGIT 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 :

3

Page 4

SCHID 201 to 231 232 to 239

[DESCRIPTION 1 st of the Month through to 31 st of the Month 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 240 to 244

DESCRIPTION Bank Holidays

8.1.13. Quarterly / Annual jobs The following Schedule IDs are used as follows SCHID 200 245 to 249 250 251 252 253 254

DESCRIPTION Half-yearly - second Monday of January and July Annual Jobs Quarterly - last day of months.: 3, 6, 9, 12 Quarterly - first Saturday of months : 1, 4, 7, 10 Quarterly - first Sunday of months : 1, 4, 7, 10 Quarterly - second Friday of months : 2, 5, 8, 11 Quarterly - third Saturday of months : 3, 6,

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 006 to 009

Reserved FReserved

019 070 to 80 124 to 128

Reserved Reserved Reserved 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:

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

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 exam ple : 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

1SL/UPS/A018 - CA- 7 Product Standards and Scheduling Techniques

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 once perthan 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, order to reduce 4. in 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 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 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.

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.