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 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 Self-Triggering / Multiple run per
064 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 Symetric
069 Schedules

8.1.6. OMS Schedule IDs

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

SCHID DESCRIPTION
081 to OMS Billing Suite
096

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 Adhoc Suites
99

8.1.8. Dataset triggered jobs

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

SCHI DESCRIPTION
D
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 2nd working day of each month etc.
123 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,

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 FReserved
009
Reserved
019 Reserved
070 to Reserved
80
124 to Reserved
128

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
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 Page 8 0.
Techniques

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
onceoften
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,
4. in order
The to reduce
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.