Page 1
ISL/OPS/A018 CA7 Product Standards and Scheduling Techniques
8. Scheduling standards and techniques
8.1. CA7 Schedule IDS
8.1.1. Noncalendar scheduled jobs
The following Schedule IDs are to be used for jobs and suites which are brought onto CA7 other than by being scheduled.
SCHID / DESCRIPTION001 / 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 / DESCRIPTION10 / 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 / DESCRIPTION011 / 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. Selftriggering / 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 / DESCRIPTION020 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 / DESCRIPTION065 to 069 / Symetric Schedules
8.1.6. OMS Schedule IDs
The following Schedule IDs will be exclusively used by the OMS Billing suite :
SCHID / DESCRIPTION081 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 / DESCRIPTION97 to 99 / Adhoc Suites
8.1.8. Dataset triggered jobs
The following Schedule IDs will be used by jobs which are dataset triggered.
SCHID / DESCRIPTION100 / 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 / ][DESCRIPTION101 / 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 DIGIT1xy / 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 / [DESCRIPTION201 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 / DESCRIPTION240 to 244 / Bank Holidays
8.1.13. Quarterly / Annual jobs
The following Schedule IDs are used as follows
SCHID / DESCRIPTION200 / 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 / DESCRIPTION002 / 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 DayWO / 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 nonschedule days
- Page 6
- D do not run on nonschedule days
- F roll forward on nonschedule days
- B roll backward on nonschedule 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 `SimpleSchedule' 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 nonschedule days
- . D do not run on nonschedule days
- . F roll forward on nonschedule days
- . B roll backward on nonschedule 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, 1117. 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 (6569), and its job name should conform to the following format
rxxShhmz where:
- . r = the roll parameter:
- . N do not roll on nonschedule days
Page 7
- . D do not run on nonschedule days
- . F roll forward on nonschedule days
- . B roll backward on nonschedule 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 nonschedule days
- . D do not run on nonschedule days .
- . F roll forward on nonschedule days
- . B roll backward on nonschedule 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 subsuite that is triggered, e.g.:
RACFHKG
BILLPROD
1SL/UPS/A018 CA7 Product Standards and Scheduling Techniques
8.3. Scheduling techniques
Note: See Database Maintenance Guide for further details
8.3.1. General techniques
Page 8 0.
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 CA7 (e.g. Day before Bank Holiday schedules;
schedules which run during software upgrades) must be defined to CA7, 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 selftriggering/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 CA7. However use of such scheduling techniques must be kept to a minimum, clearly documented on schedule diagrams, and detailed in Job Procedures. Standard CA7 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, 0198 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 CA7, 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 CA7 at queue entry time as current time + QTM (queue time) + CLOCKTIME (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 CLOCKTIME=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 CLOCKTIME, e.g. because it abends frequently, the LEADTM must be set to the maximum expected run time of the job, and the CLOCKTIME 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.