CTLM STD

IBM Global Services Australia
MVS Production Support
a joint venture with Lend Lease and Telstra
Production CONTROL-M Standards
PRODUCTION MANAGEMENT GROUP
CONTROL-M STANDARDS
Document Owner: Production Management

Group Manager Lance Wright
Document Author: Bruno Cimiotti
Business Unit: Enterprise Services
Technical Support
Department: Production Management Group
Application Management
Mailing address: 18 Winterton Road
Clayton Vic 3168
Voice: + 61 (03) 9253 0727
Email: bruncimi@au1.ibm.com
Total Pages: 35
Document Version: 5.0
Print Date: 30/03/14
This document contains proprietary information. ALL INFORMATION CONTAINED

HEREIN SHALL BE KEPT IN CONFIDENCE. None of this information shall be
divulged to persons other than IBM Global Services employees authorised by the
nature of their duties to receive such information, or individuals or organisations
authorised by IBM Global Services in accordance with existing policy regarding release
of company information.
G:\Prodsupp\standard\PASTMPS.DOC
For Internal IBM GSA Use Only
Enterprise Services
Page 1
Printed 30/03/2014

Document Control
Issue No
Issue Date
V3.0
January 1996
V3.1
September 1997
V3.2
August 1998
V4.0
September 1998
V5.0
June 2001
Nature of Amendment
Major revision
Manual IN condition to hold jobs;
General Revision
Annual review of document & Update.
Major Revision.
Enterprise Services
Page 2
Printed 30/03/2014

Contents
1.0
1.0 INTRODUCTION.....................................................................................................................................4
1.2 CREATION OF CONTROL-M PRODUCTION BATCH USERID...............................................................4
1.3 FORMAT OF CONTROL-M PRODUCTION BATCH USERID .................................................................4
2.0 JOB SCHEDULING DEFINITIONS STANDARD.........................................................................................5
DAYS, WDAYS, DCAL, WCAL & CONFCAL......................................................................................8
MONTHS...................................................................................................................................................9
MAXWAIT................................................................................................................................................9
2.8 AUTO-ARCHIVE.................................................................................................................................13
2.10 SYSOUT REDIRECTION..................................................................................................................15
2.11 ABEND CODES CAPTURE.................................................................................................................16
2.12 CONTROL-R SUITABILITY & STANDARDS....................................................................................18
SUITABILITY...........................................................................................................................................18
STANDARDS..............................................................................................................................................19
2.13 SHOUT...........................................................................................................................................20
ABBREVIATED SHOUT PARAMETERS......................................................................................................22
3.0 GROUP SCHEDULING STANDARD.......................................................................................................23
3.2 STANDARDS AND CONSIDERATIONS..................................................................................................23
4.0 MIGRATION & CONTROL-M LIBRARIES STANDARD..........................................................................26
5.0 NEW DAY PROCESSING STANDARD...................................................................................................29
.................................................................................................................................................................30
5.2 TELSTRA STANDARD FOR NEW DAY PROCESSING.............................................................................30
6.0 CONTROL-M UTILITIES......................................................................................................................31
COPY OF JCL AVAILABLE ON VI2 IVPSUPP.CTMFLOW.CNTL(LASER)...................................32
6.2 MAYBE UTILITY..............................................................................................................................33
WHERE DESIRED OR NECESSARY, THE ABOVE UTILITY MAY BE SET-UP TO ADD CONDITIONS FOR THE
CURRENT OR SPECIFIC ODATE. IN WHICH CASE, THE FOLLOWING CODING WILL APPLY: ....................34
7.0 APPENDIX A......................................................................................................................................35
Enterprise Services
Page 3
Printed 30/03/2014

1.0 Introduction
1.1 Scope
The purpose of this document is to outline the standards to be
followed by the Production Management Group when building
new jobs or jobflows within the Control-M Production
environment.
This document is to be used in conjunction with the OS/390
Applications Batch Scheduling Standards Document.
For more in depth details and examples how to use the many ControlM/R features, consult the Control-M/R User Manual as supplied by the
vendor.
Should there be a requirement to deviate from any of the standards
mentioned in this document, PRIOR approval must be obtained from
either the respective Team Leaders or the Manager of Production
Management Group.
1.2 Creation of Control-M Production Batch USERID

A Production Batch USERID has to be created for EACH
application running under Control-M.
A 'MVS Userid Details' form must be filled out and signed by the
Application Project Manager (and submitted to the Operations Security
Group) to request for the userid creation.
1.3 Format of Control-M Production Batch USERID

The Production Batch USERID will be created in the following format:
PSaaann
where: PS = Production Support
aaa = Abbreviation of Application Name
nn = two digits number
Once the userid created, a 'Request For Control-M Access For
Production' form needs to be filled out by the Production Management
Group representative and forwarded to Operations Security and then to
the Batch Software Support group. This form requests for the creation
of a surrogate profile and the relevant Control-M datasets. See
Appendix A for an example of the form.
Enterprise Services
Page 4
Printed 30/03/2014

2.0 Job Scheduling Definitions Standard

2.1 Application & Job Specific Definitions
MEMNAME QTIPUT20
MEMLIB
TPIOA.TIPPS.CNTL.D%%ODATE
OWNER
PSTIP01
TASKTYPE JOB
PREVENT-NCT2
APPL
TIPPS
GROUP TIPPS-TIPHR
DESC
BACKUP CUSTOMER ORDER FILE
OVERLIB
SET VAR %%SYMVARXX=VARPROD
CTB STEP AT
NAME
TYPE
DOCMEM QTIPUT20
DOCLIB
TPIOA.TIPPS.RUNBOOK
MEMNAME
Normally coded with the same name as the JOBNAME within
the JCL (job card).
MEMLIB
Refers to the dataset where the job JCL is stored.
Format: TPIOA.application name.CNTL.D%%ODATE
OWNER
Refers to the Control-M batch userid. Must be unique for every
Applications and ONLY be defined and set-up to submit jobs on
PRODUCTION Lpars.
TASKTYPE
The two most common values coded for this field are:
- JOB (for the standard batch job/jcl submitted).
- CYC (for a cyclic job submitted).
PREVENT-NCT2
This field should be left blank to pick up the default of NO for
preventing Not Catalog 2 abends. There may be specific
instances where this field may be set to Y (yes) but great care
must be taken to ensure that you want Control-M to
automatically delete datasets when performing a RESTART.
APPL
Refers to the name of the application (eg: TIPPS).
GROUP
Should be unique for each application.
Format: Application Name-Table name
For Example: TIPPS-TIPMUTIL
Enterprise Services
Page 5
Printed 30/03/2014

DESC
Refers to a description on the jobs function. Coded in a free
form text format up to 50 characters in length. All job schedules
must have a description in this field.
For Example: BACKUP CUSTOMER ORDER FILE
OVERLIB
Refers to the JCL library name that overrides the MEMLIB field.
Useful for running one off version of production JCL. However,
must be removed prior to next scheduled production run to avoid
reference being made again to this one off version.
Format: TPIOA.application name.OVRD
For Example: TPIOA.TIPPS.OVRD
SET VAR
Is used to substitute user defined variables within the JCL at job
submission time.
Eg:
SET VAR %%PRD=2PRD1 - in this example all %
%PRD references within the JCL will be substituted to
2PRD1.
For those Applications using extensive variable substitutions
within their JCL, it is recommended to use a LIBSYM and a
MEMSYM to store all the variables values.
The LIBSYM/MEMSYM will be a PDS (dataset) that will house
all the variables values. In the example illustrated above, the
SET VAR statement within the Job Scheduling Definition is
pointing to a member called VARPROD.
Within all the JCL members belonging to the Application, the
following is defined as LIBSYM and MEMSYM:
//* %%LIBSYM TPIOA.TIPPS.CNTL
%%MEMSYM %%SYMVARXX
//*
//%%JOBPREF%%.SC06 JOB (%%ACCOUNT),'TIPPS',
//
CLASS=%%HIGH,
//
MSGCLASS=%%MSGCLASS,
//
MSGLEVEL=%%MSGLEVEL,
//
REGION=0M
In the above JCL at run time the value %%SYMVARXX will

be substituted to VARPROD.
In turn, the VARPROD member within the LIBSYM
TPIOA.TIPPS.CNTL will contain all the variable values, as
follows:
EDIT
TPIOA.TIPPS.CNTL(VARPROD) - 01.00
00072 Command ===>
000012 %%JOBPREF = QTIP
000013 %%MSGCLASS = 4
000014 %%ACCOUNT = QTIPPS000
Enterprise Services
Columns 00001
Scroll ===> HALF
Page 6
Printed 30/03/2014

One of the main advantages the above offer is the ability to

migrate the VARPROD member in production as part of the
migration tool and methodologies being used by the Customer or
Application (eg. as an Endevor package).
CTB STEP AT
Is used for CONTROL-B definition. NOT used in OUR
environment.
DOCMEM
Refers to a member within the DOCLIB containing the
Restart/Recovery and/or escalation instructions for when the job
abends. This member will also contain the actions to be taken by
the operator when the job is running/submitted late. The name is
normally the same as the MEMNAME (unless it is a generic
runbook used by a number of jobs).
DOCLIB
Refers to the library name in which the DOCMEM mentioned
above resides
Format: TPIOA.application name.RUNBOOK
Enterprise Services
Page 7
Printed 30/03/2014

2.2 Calendar Scheduling Criterias Definitions

DAYS
DCAL *
WDAYS
MONTHS
AND/OR
2,3,4,5,6
WCAL *
1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
DATES
CONFCAL TIPFRIMN SHIFT

MINIMUM
PDS
RETRO N MAXWAIT 03
D-CAT
DAYS, WDAYS, DCAL, WCAL & CONFCAL

The above fields are used to specify when (date) the intended
job is to be scheduled (run).
For simple run criteria it is recommended to use the DAYS
or WDAYS option (e.g. run job Monday to Friday, every
Sunday, last day of the month etc.). By so doing it reduces the
need to maintain and create new calendars at/before year-end.
In the above example the job will run MON-FRI (i.e. 2,3,4,5,6).
The default for WDAYS (i.e. for Control-M set-up on the Telstra
Account) is: 1 for Sunday, 2 for Monday, 3 for Tuesday, 4 for
Wednesday, 5 for Thursday, 6 for Friday, & 0 for Saturday.
Refer to the Control-M User Manual for a detail explanation how
to use the different combinations of the DAYS and WDAYS
options.
For more complex run criteria, the user can create its own user
defined calendar. In the above example a user defined calendar
of TIPFRIMN has been created.
The recommended naming standard for CONFCAL is to code it
the SAME name as the Control-M schedule (table) member
name. However, if more than one calendar name is used within
the table, it must be prefixed with the Application acronym.
It is important to note that if any entry is made within the
CONFCAL field that the DCAL & WCAL fields are
commented with an *. Failure to do so will cause jobs NOT to
be scheduled.
Note:
All user defined calendars are stored in one central library
TPIOA.IOA.PROD.CAL.
Enterprise Services
Page 8
Printed 30/03/2014

MONTHS
This field refers to the months the job will be scheduled. A Y
entry means the job will be scheduled to run on the given month
and a N or blank means the job will not be scheduled
RETRO
The recommended standard is to code this field as N. If
selected (ie. Y) it will set the job to run if the original date has
passed. Normally applicable to control situations where the
computer has not been working for a day or more. This is highly
unlikely in our current environment!
MAXWAIT
This field refers to how long a job in Wait Status will be kept in
the AJF after being loaded either manually or at/by the new day
processing. The recommended standard is to code at least 3
(for 3 days). However, depending on the Customer or
Application requirements, this figure might vary. It is important to
note that the longer and the more jobs are kept in the AJF, the
potential increases for the AJF to become full and this may lead
to problems.
All other fields must be left blank.
Enterprise Services
Page 9
Printed 30/03/2014

2.3 IN-CONDITION Definitions

IN
LPAR-NI2-AVAIL
QTIPBK01-TIPHR-OK
STAT
ODAT
APPLIC-TIPPS-AVAIL
QTIPSR06-TIPHR-OK
STAT
ODAT
MANDATORY In-Condition
This field refers to any Prerequisite Conditions that are to be
satisfied before the job can run.
As illustrated in the above example, the following are the two
MANDATORY in-conditions that are to be included on all jobs:
- LPAR-ddd-AVAIL
STAT
- APPLIC-name-AVAIL
STAT
where:
- 'ddd' is the LPAR where the job is EXECUTING.
- 'name' is the name of the Application the job belongs to.
The STAT parameter is used, as those conditions are NOT
date dependant and therefore not deleted as part of the daily
Control-M housekeeping.
The main purpose of having the above two conditions is to allow
the flexibility to quickly STOP any further batch jobs from being
submitted by simply deleting the two conditions (eg. in event of a
major problem). This may prevent any further and unnecessary
abends as soon as problems are identified. It can also be useful
for the Operators/Operations Analyst before scheduled IPL are
performed - eg. 30 minutes before the IPL the conditions can be
deleted to stop any further jobs from being submitted and thus
being cancelled in mid-flight.
JOB In-Condition
The following is the standard for coding job in-condition:
- JobName-Table Name-OK
ODAT
- JobName-Table Name-OKnn
ODAT
where:
- Table Name is the name of the Control-M Table the job
resides in must NOT be more than 6 character long.
- nn = is a two numeric digit to be used if the job is running
more than once within the same flow (ie. in the 1st run it will
be set as .OK01, the 2nd run .OK02 etc.).
Note:
The ODAT parameter will be automatically replaced by
the current Original Scheduling Date when the job is
loaded into Control-M for execution.
Other values that can be used instead of ODAT are as
follows :
- PREV: job's previous scheduled date.
Enterprise Services
Page 10
Printed 30/03/2014

- Ddmm:
- NEXT:
- $$$$:
- ****:
- STAT:
date and month of schedule date.

jobs next schedule date.
any schedule date.
any schedule date.
as explained above.
Important: when using the PREV option, BOTH the job

and the job it is dependent on MUST have run on the
previous date for the conditions to be satisfied.
MANUAL In-Condition
In circumstances where a MANUAL hold is required on a job, the
following is the standard to be adopted:
aaaaaaaa-nnnnnn-OK ODAT
where: aaaaaaaa = application name
nnnnnn = the Task No. requesting the manual
hold or name of the person that will request the
job to be released.
INTERFACE In-Condition
If the application is interfacing (ie. producing an in-condition) for
a downstream application, the following is the standard to be
adopted:
Application Name-Job Name-OK
ODAT
where: Application Name = the name of the
application SENDING the data or adding the
condition.
Job Name = the Job Name that is creating the
data for the downstream application.
Enterprise Services
Page 11
Printed 30/03/2014

2.4 OUT-CONDITION Definitions

OUT
QTIPUT20-TIPHR-OK
ODAT +
JOB Out-Condition
The same standards as per the in-condition will be applicable JobName-Table Name-OK
ODAT +
Should a job run more than once within a given table, the
following is the standard to be adopted:
- on the 1st run it will produce the following out-condition:
JobName-Table Name-OK1
ODAT +
- on the 2nd run it will produce the following out-condition:
JobName-Table Name-OK2
ODAT +
and so on.
2.5 F.Y.I Housekeeping of Condition & Resource File

As part of the regular housekeeping, Conditions are deleted from
the Condition & Resource File by the Control-M Administrator.
Currently the deletion is run once a week as part of the newday
processing, where any condition older than 6 days (or up to 15
days on certain Control-M) are deleted. Exemption lists exist
where specified conditions are ignored and therefore NOT
deleted. If an application has a special requirement, contact the
Control-M administrator to define the special business need.
2.6 RESOURCE Definitions (Quantitative & Control)

CONTROL REORG-FLEXCAB
E
RESOURCE BACKUP-FLEXCAB-TAPE
0003
Both the Quantitative and Control resources must include the

Application Acronym as part of the name to make identification and
ownership easier as illustrated in the example above.
Enterprise Services
Page 12
Printed 30/03/2014

2.7 Run TIME Definitions

TIME: FROM 2100
UNTIL >
The FROM field dictates the time (if required) the job will be submitted
for processing. In the above example the job will be submitted at 21:00
hrs. It is important to note that if by 12:00 (midday) on the next day the
job has not run, Control-M by default will NOT allow/submit the job to
run.
If it is ok for the application to run any left over jobs on the next
scheduled odate (ie. after midday), then the greater than sign >
as indicated in the above example must be coded in the UNTIL
field.
2.8 Auto-Archive
AUTO-ARCHIVE Y
SYSDB
SYSOUT OP
(C,D,F,N,R)
MAXDAYS
MAXRUNS
FROM
AUTO-ARCHIVE
This field controls SYSDATA archiving. It allows the user to
decide whether or not to archive SYSDATA. The standard is to
code Y (for yes).
SYSDB
This field archives SYSDATA of all jobs to a common data set.
The standard is to code Y (for yes).
2.9 Automatic Restart

It is recommended that wherever possible an automatic rerun is invoked
for batch abend - eg. for data transmission failure. This will avoid the
unnecessary manual intervention and speed up batch jobs restart.
In the example below, if step BACKUP fails with code U0034, an
automatic rerun will be performed after an interval of 15 minutes.
The MAXRERUN will be initiated 8 times unless the step ends
with a user code other than U0034.
RERUN - MAXRERUN 8
RERUNMEM
STEP RANGE
FR (PGM.PROC)
ON PGMST BACKUP
PROCST
DO RERUN
DO
Enterprise Services
.
CODES U0034
INTERVAL 015
TO
.
A/O
Page 13
Printed 30/03/2014

The DO SET control statement can be used to alter variables

before the job is rerun.
The following is an example how to automatically rerun a job and use
Control-R to change the value of a variable in the restart:
SET VAR
%%CYL=50
RERUN - MAXRERUN 1
RERUNMEM
INTERVAL
ON PGMST ANYSTEP PROCST
CODES EXERR
DO IFRERUN
FROM $EXERR
.
TO
DO
ON PGMST CREATE
PROCST
CODES SB37
DO SET
VAR= %%CYL=100
DO RERUN
NEXT TIME
A/O
CONFIRM N
A/O
The initial SET VAR statement sets the value of %%CYL=50. If the
jobs fails in step CREATE, it is automatically rerun once after a 1
minute interval and with a value of 100 for %%CYL. If any other
step fails, the job will have to be manually restarted by the
Operations Analyst and the value of %%CYL remains at 50.
With an Automatic job Restart, if only one shout message is required
for multiple abends, then *REC0 must be coded (see example
below). *REC0 will determine if a rerun is needed but no more reruns
are available. Only when this status code is posted do we issue the
SHOUT command. In other words, only the last rerun will raise an
alert if the job fails.
CODES *REC0
DO SHOUT
TO U-ESO
URGENCY V
= ALERT=Y,PROBLEM=Y,SEVERITY=4,SYSID=VI2
Enterprise Services
A/O
Page 14
Printed 30/03/2014

2.10 SYSOUT Redirection

STEP RANGE
FR (PGM.PROC)
DO SYSOUT
OPT N PRM VIL
DO SYSOUT
OPT R PRM
DO SYSOUT
OPT C PRM 4
DO
.
CODES *****
TO
.
A/O
FRM
FRM
FRM H
STEP RANGE
This field contains a number of DO SYSOUT statements which
must be defined to allow Control-M to pass the SYSOUT of the
job to the relevant Output Management System (eg. OMCS).
ON PGMST
The standard is to code ANYSTEP this identifies the actions
Control-M needs to take (as specified in the subsequent DO
statements) when the job steps completes.
CODES
The standard is to code ***** - this causes the actions defined
in the subsequent DO statements to be applied to the job
whether it completes processing normally or abnormally.
DO SYSOUT
This is the DO statement instructing Control-M what to do with
the SYSOUT of the completed job.
- OPT N: will change the destination of the
SYSOUT
- PRM VIL: will place the new system ID (VIL in the above
example) on the SYSOUT of the job so that it is
routed to the required Lpar.
- OPT R: will release the SYSOUT from being held
(when Control-M receives the SYSOUT it
always places it in the held status)
- OPT C: will change the output class of the job's
SYSOUT.
- PRM 4: will place the SYSOUT in a new output class (4 in
the above example).
- FRM H: instructs Control-M that the output class is being
changed (from H in the above example).
Enterprise Services
Page 15
Printed 30/03/2014

2.11
Abend Codes Capture

The standard is for ALL Application JCL to be self-sufficient and have
appropriate condition code checking included in them. Therefore, the
JCL condition code will dictate when the job should complete
successfully or unsuccessfully.
Should the Control-M definition screen be used to perform condition
code checking, it will increase maintenance and coding.
The following is the recommended standard when coding new job
definitions:
ON PGMST ANYSTEP
DO IFRERUN
PROCST
FROM $EXERR
CODES EXERR
TO
A/O
CONFIRM N
In the above it is indicating for Control-R to restart the job from the
step which failed. By so doing this will automatically insert the failed
Step Name in the restart window that is invoked by the
Operators/Operations Analyst - ie. when they are performing a manual
restart. See examples below.
Note:
If Control-R CANNOT be used when restarting the job, then DO
IFRERUN must be omitted and the runbook must clearly state
that this job is not Control-R restartable.
Example 1: WITHOUT CONTROL-R
FILTER:
----- CONTROL-M ACTIVE ENVIRONMENT ----------------------(3)
COMMAND ===>
SCROLL===> CRSR
O NAME
OWNER
ODATE JOBNAME JOBID TYP --------- STATUS ----------- UP
====== >>>>>>>>>>>>>>>>>>>> TOP OF ACTIVE JOBS LIST <<<<<<<<<<<<<<<<<<<< ======
R QREB2440 PSREB01 030998 +--------------------------------------+
QREB2450 PSREB01 140998 | JOB
QREB2440
WILL BE RERUN |
====== >>>>>>>>>>>>>>>>>>> | PLEASE CONFIRM
(Y/N) | <<< ======
| WITH
RESTART N
(?/Y/N) |
| ---------------------------------- |
| FROM
STEP
.
|
| TO
STEP
.
|
| RECAPTURE ABEND CODES
(Y/N) |
| RECAPTURE COND CODES
(Y/N) |
| STEP ADJUSTMENT
(Y/N) |
| RESTART PARM MEMBER NAME QREB2440 |
+--------------------------------------+
Example 2: WITH CONTROL-R

FILTER:
----- CONTROL-M ACTIVE ENVIRONMENT ----------------------(3)
COMMAND ===>
SCROLL===> CRSR
O NAME
OWNER
ODATE JOBNAME JOBID TYP --------- STATUS ----------- UP
QREB2440 PSREB01 030998 QREB2440/10334 JOB ENDED "OK"
R QREB2450 PSREB01 140998 +--------------------------------------+
====== >>>>>>>>>>>>>>>>>>> | JOB
QREB2450
WILL BE RERUN | <<< ======
| PLEASE CONFIRM
(Y/N) |
| WITH
RESTART Y
(?/Y/N) |
| ---------------------------------- |
| FROM
STEP
DELETE
. STEP01
|
| TO
STEP
.
|
Enterprise Services
Page 16
Printed 30/03/2014

| RECAPTURE ABEND CODES

(Y/N) |
| RECAPTURE COND CODES
(Y/N) |
| STEP ADJUSTMENT
(Y/N) |
| RESTART PARM MEMBER NAME QREB2450 |
+--------------------------------------+
If a ? is entered in the WITH RESTART field, a further window is displayed which

will list all of the available restart steps within the job. A selection can be made from
this list.
R QREB2450 PSREB01
140998
+--------------------------------------------+
| COMMAND ==>
|
| O Num Pgm-stp Proc-stp Pgm=
Comp
|
|
001 DELETE
STEP01
IEFBR14
C0000 |
|
002 STEP02
IEBGENER C0000 |
|
003 STEP03
IEBGENER C0000 |
|
004 IOATEST STEP04
IOATEST
C0080 |
|
005 IOATEST STEP05
IOATEST
C0000 |
|
006 STEP06
IEBGENER C0000 |
|
007 STEP07
IEBCOPY
C0008 |
|
008 STEP08
IKJEFT01 C0000 |
|
009 STEP99
ABEND999 FLUSH |
|
|
| Opt: F From T To O Only
|
+--------------------------------------------+
Enterprise Services
Page 17
Printed 30/03/2014

2.12 CONTROL-R Suitability & Standards

Suitability
Control-R may or may not be suitable for some jobs or Applications.
The following are the issues that must be considered when using
Control-R:
Duplicate stepname
A duplicate procstep.pgmstep name will cause the Control-R step
to fail. Every stepname must be unique.
Missing stepname
A null stepname will also cause the Control-R step to fail. Every
step must have a unique name.
Backward references
- A backward reference in the VOL= field will cause Control-R to
adjust the restart step to prevent a JCL error.
- A backward reference in the PGM= field will not cause Control-R
to adjust the restart step but a JCL error will occur.
- A backward reference in the DSN= field is OK and does not
require restart step adjustment.
- As a general rule any jobs with a backward reference in the VOL
field must be studied to determine if the restart step adjustment
matches the restart action as described in the runbook.
- There is a restart option in the Control-R confirmation window
which will disable step adjustment, but this must be clearly
specified in the runbook if the Operations Analyst are to set this to
N. The default value for STEP ADJUSTMENT is Y.
DISP=MOD
Any jobs which writes to a dataset with DISP=MOD probably has
to restore the dataset before restarting or else risk duplicate
records. Check the runbook for the correct restart action.
PGM=FTP
The EXEC statement must include PARM=(EXIT=8) otherwise a
condition code of 0 is always returned and Control-R will not know
if the FTP has ended successfully or not.
GDG usage
Control-R will use the same generations as the original job. If a
new input GDG generation is to be used or the project team do not
want the output generation to be scratched and reallocated, then
do not use Control-R.
Checkpoint restarts
Some applications use a GDG(+1) as the checkpoint dataset.
Control-R will delete this as part of its GDG adjustment processing
and this also applies to any checkpoint dataset referred to as
DISP=NEW. Control-R will delete it so that it can be reallocated in
the restart. A checkpoint restart will not be very successful with an
empty checkpoint dataset so ensure that GDGs or DISP=NEW
are not used for checkpoint datasets or else preallocate them in a
previous step and subsequently refer to them as generation 0 or
DISP=SHR.
Enterprise Services
Page 18
Printed 30/03/2014

Standards
It is important to note that when processing COND or
IF/THEN/ELSE statements that are not stepname specific, errors
in restarts might occur. See the following example:
//STEP1
EXEC
PGM=...
//IF1 IF (RC = 0) THEN
//STEP2
EXEC PGM=...
//STEP3
EXEC PGM=...
//STEP4
EXEC PGM=...
//IF2 IF (RC LE 8 OR RC = 80) THEN
//STEP5
EXEC PGM=...
//STEP6
EXEC PGM=...
//IF2E ENDIF
//IF1E ENDIF
Ends with CC=0000

Ends with CC=0000
Ends with CC=0000
Ends with CC=0080
This is OK
Ends with CC=0000

Ends with CC=0008
Error
When Control-R tries to restart from STEP6, the job skips all steps
and ends OK. Control-R appears to retrieve CC=0080 from
STEP4 and applies this value to the IF1 statement thereby
determining that steps 2 to 6 must not be run.
To get around this problem, the IF statement must be coded
with the specific stepname to which it applies:
Eg. //IF1 IF (STEP1.RC = 0) THEN
Bypassing failed steps using Control-R
Exercise caution if attempting to use Control-R for restarts where
the resolution is to skip the failed step and continue from a
subsequent step. If there is condition code checking in the
jobstream there may be situations where a job will have a status
of ENDED OK but none of the job steps have executed apart
from the Control-R step. See the following example:
//STEP1
EXEC
//
IF (RC.STEP1 =
//STEP2
EXEC
//STEP3
EXEC
//STEP4
EXEC
//
ENDIF
PGM=...
0) THEN
PGM=...
PGM=...
PGM=...
Ends with CC=0008
If STEP1 has a condition code of 8 and the job is restarted from

STEP2 using Control-R, the condition code will be retrieved from
STEP1 and applied to the IF statement, therefore STEP2,3,& 4
will be bypassed. As the Control-R step has executed and
finished with condition code 0, Control-M thinks that the job
ended successfully with a condition code 0 in all steps that were
executed and releases the next job.
There is a restart option in the Control-R confirmation window
that will determine if condition code recapture is performed or
not. In this example, Control-R will restart the job from STEP2
provided RECAPTURE CONDITION CODES is set to N. The
default value for RECAPTURE CONDITION CODES is Y,
therefore it must be clearly specified in the runbook if the
Operations Analyst are to change the value to N.
Enterprise Services
Page 19
Printed 30/03/2014

2.13 SHOUT
SHOUT information is used to prompt the automation tool (Solve
Operations) to automatically issue alerts and generate Problem
Dockets.
SHOUT WHEN
NOTOK
TO
U-ESO
MS
ALERT=Y,PROBLEM=Y,SEVERITY=4,SYSID=NI2
URGN
The following are valid parameters for the SHOUT WHEN field:
SHOUT WHEN NOTOK
Shouts a message everytime the job ends with an error code.
SHOUT WHEN LATESUB
Shout a message if the job has not been submitted by the
specified time (see example below).
SHOUT WHEN LATE
Shout a message if the job has not finished after a specified
period of time ie. after initial submission (see example below).
SHOUT WHEN EXECTIME >n
Shout a message if the execution time is greater than a specified
time period.
TO U-ESO
This will instruct Control-M to shout the message to the
automation tool Solve Operations.
URGN V
This will instruct Control-M that the message is very urgent and
to send it immediately.
MS ALERT=Y, PROBLEM=Y,SEVERITY=4, SYSID=NI2
This will instruct Solve Operations to: 1) raise an alert, 2)
generate a problem docket, 3) make the severity of the problem
docket 4 and 4) the system ID NI2 this refers to the lpar where
the job is executing. Higher severity number can be allocated for
critical jobs.
ALERT=Y,SEVERITY=n,TEXT='message' - this can be used to
send messages to the operator.
Examples
SHOUT WHEN
LATE 0600
TO U-ESO
URGN
MS
ALERT=Y,PROBLEM=Y,SEVERITY=4,SYSID=NI2,LATE=EXEC
In the above example Solve Operations will generate an alert if the job
hasn't finished executing by 0600.
Enterprise Services
Page 20
Printed 30/03/2014

SHOUT WHEN
LATESUB 2100
TO U-ESO
URGN
MS
ALERT=Y,PROBLEM=Y,SEVERITY=4,SYSID=NI2,LATE=SUB
hasn't been submitted by 2100.
SHOUT WHEN
EXECTIME > mmm
TO U-ESO
URGN
MS
ALERT=Y,PROBLEM=Y,SEVERITY=4,SYSID=NI2,LATE=EXECTIME
hasn't finished executing within mmm minutes.
SHOUT WHEN
EXECTIME < mmm
TO U-ESO
URGN
MS
finishes executing within mmm minutes
The examples illustrated below shows shout parameters that depend on the
existence of job statistics for the job in question. If the job has not run before,
the shout command won't work and an error message will be sent to the log
file. See example log statements below for job 'TESTSHEX'. This shows
shout parameters being ignored due to missing job statistics.
180394 112544 170394 IV04557
180394 112548 170394 IV04557
180394 112554 170394 IV04557
180394 112809 170394 IV04557
180394 112814 170394 IV04557
SEL203I JOB TESTSHEX ELIGIBLE FOR RUN

SUB1A7I JOB TESTSHEX MISSING JOB STATISTICS.
SHOUT WHEN EXECTIME PARAMETER IGNORED
SUB133I JOB TESTSHEX TESTSHEX/11591 SUBMITTED
SPY254I JOB TESTSHEX TESTSHEX/11591 SCANNED
SEL208I JOB TESTSHEX TESTSHEX/11591 ENDED "OK"
SHOUT WHEN
EXECTIME + nnn
TO U-ESO
URGN
MS
elapsed runtime is nnn minutes more than its average elapsed runtime.
SHOUT WHEN
EXECTIME - nnn
TO U-ESO
URGN
MS
total elapsed runtime is nnn minutes less than its average elapsed
runtime.
Enterprise Services
Page 21
Printed 30/03/2014

Abbreviated SHOUT Parameters

The Solve Operations/Control-M interface has been modified to accept
abbreviations of the SHOUT parameters SEVERITY and PRIORITY to
allow more space for TEXT messages. Both the abbreviated form and
full form of these parameters are accepted in these fields.
SHOUT WHEN NOTOK
TO U-ESO
URGN V
MS
ALERT=Y,PROBLEM=Y,SEVERITY=3,PRIORITY=7,SYSID=B01,TEXT=TEST MSG
The above parameters can be abbreviated to:

SHOUT WHEN NOTOK
TO U-ESO
URGN V
MS
ALERT=Y,PROBLEM=Y,SEV=3,PRI=7,SYSID=B01,TEXT=TEST MSG TEST MSG TEST
Enterprise Services
Page 22
Printed 30/03/2014

3.0
3.1
Group Scheduling Standard

Overview
Defining Scheduling Tables as 'Group Scheduling' is another option
that may be suitable and used when defining the Application under
Control-M.
Jobs that are to be handled as a group (this includes their scheduling,
submission and post-processing) must be defined in their own
scheduling table called a Group scheduling table. This table must be
created with the Group attribute as specified in the entry panel.
At time of creation of a Group scheduling table, a special scheduling
definition, called a Group Entity, is created. The Group Entity is used
to define job processing criteria for the group as a whole. With batch
runs that contain a large number of batch jobs, the use of the Group
Scheduling Facility is recommended.
Refer to the Control-M User Manual for more information.
3.2
Standards and Considerations

Standards
GROUP ENTITY naming standard:
Application Name-Table Name
Eg: FLEXCAB-BILLING
SCHEDULE TAG naming standard:
Application Name _ meaningful run criteria
Eg: FLEXCAB_MON_FRI
Considerations
Any scheduling changes (eg. do not run the flow on Friday) can be
simply made and controlled via the SCHEDULE TAG in the
Group Entity).
Any Application schedules/tables that have been created in the
normal fashion but would like to start using Group Scheduling,
must first be converted using the utility CTMBGRP. See the
Control-M User Manual for more details.
Using the option ADJUST CONDITIONS in the Group Entity is an
alternative to using the IOALDNRS and ADDMNCND utilities.
However, the main restriction is that Conditions will only be
adjusted (satisfied automatically) if the jobs are from the same
group. It does not allow the flexibility for job dependencies
(conditions) across different flows but within the same application
to be managed using this method.
Enterprise Services
Page 23
Printed 30/03/2014

Individual jobs from within a table cannot be manually ordered

when using Group Scheduling. Instead, they will need to be
forced in.
The Group Entity cannot be DELETED or FORCE OK from the
AJF.
The Group Entity can be used to add a condition or force another
table/job on completion of ALL the jobs within the table.
Example of a Control-M flow using Group Scheduling
Group Entity & Schedule Tag DEFINITIONS:
| GROUP FLEXCAB-BILLING
MEMMNAME FLEXCAB
|
| OWNER
IV04702
|
| APPL
FLEXCAB
|
| DESC
GROUP SCHEDULING FOR TIPPS
| Group
Entity
| ADJUST CONDITIONS Y
|
| SET VAR
|
| DOCMEM FLEXCAB
DOCLIB
TPIOA.FLEXCAB.RUNBOOK
|
| =========================================================================== |
| SCHEDULE TAG FLEXCAB_MONTHLY
|
| DAYS
L01
DCAL
|
|
AND/OR A |
| WDAYS
1
WCAL
| Run:Last
day of
| MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
| month is
Sunday
| DATES
|
| CONFCAL
SHIFT
RETRO N MAXWAIT 00
|
| =========================================================================== |
| SCHEDULE TAG FLEXCAB_MON_FRI
|
| DAYS
DCAL
|
|
AND/OR
|
Run:Monday-Friday
| WDAYS
2,3,4,5,6
WCAL
|
|
| DATES
|
| CONFCAL
SHIFT
RETRO N MAXWAIT 03
|
| =========================================================================== |
| SCHEDULE TAG FLEXCAB_WEEKLY
|
| DAYS
DCAL
|
|
AND/OR
|
Run:Friday
| WDAYS
6
WCAL
|
|
| DATES
|
| CONFCAL
SHIFT
RETRO N MAXWAIT 00
|
| =========================================================================== |
The idea behind the Group Scheduling concept is for individual jobs within the actual
jobflow to refer to the one Group Entity and Schedule Tags as defined above. In the
example below job QFCBSTRT is referring to the Schedule Tag
FLEXCAB_MON_FRI.
| MEMNAME
QFCBSTRT
MEMLIB
DUMMY
|
| OWNER
IV04702
TASKTYPE JOB
PREVENT-NCT2
Enterprise Services
Page 24
Printed 30/03/2014

| APPL
FLEXCAB
GROUP FLEXCAB-BILLING
|
| DESC
JOB TO INDICATE START OF THE BILLING FLOW
|
| OVERLIB
|
| SET VAR %%SYMVARXX=VARPROD
|
| SET VAR
|
| CTB STEP AT
NAME
TYPE
|
| DOCMEM
QFCBSTRT
DOCLIB
TPIOA.FLEXCAB.RUNBOOK
|
|
============================================================
=============== |
| SCHEDULE TAG FLEXCAB_MON_FRI
|
| SCHEDULE TAG
|
| RELATIONSHIP (AND/OR) O
|
| DAYS
DCAL
|
|
AND/OR
|
| WDAYS
WCAL
|
| MONTHS 1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10Y 11- Y 12- Y
|
| DATES
|
| CONFCAL
SHIFT
RETRO N MAXWAIT 00 D CATEGORY
|
| MINIMUM
PDS
|
Enterprise Services
Page 25
Printed 30/03/2014

4.0
4.1
Migration & Control-M Libraries Standard

Migration to Production
All migrations to the Application Production environment must be done
under the control of Control-M.
A separate Migration Control-M Table must be set-up with jobs to
migrate the relevant components.
The golden rule that must be adhered to is that NO Production job
must be activated to run in Control-M unless a valid JCL and Runbook
member has been reviewed and migrated into their respective libraries
as described below.
4.2
Schedule Libraries
The following is the naming standard for Applications Schedule
Libraries:
- TPIOA.application name.SCHEDULE (library from which jobs are
ordered from and referred to by the User Daily)
- TPIOA.application name.SCHEDULE.MASTER (master library

containing the CURRENT version of all the production flows)
- TPIOA.application name.SCHEDULE.PREPROD (staging library used

to make any changes or park any work currently in progress)
Refer to the CTMSCHED.DOC document for the process to be

followed when making any updates to the Application Control-M
Schedules libraries.
It also recommended for a back-up copy of the Application Schedule
Library (ie. TPIOA.application name.SCHEDULE) to be taken daily
prior to start of business hours. The following is a sample JCL to
perform this function:
//QSTASCHD JOB IQCASQE000,'START'
//*
%%SET %%DSNDEL=%%CALCDATE %%ODATE -4
//*
//STEP10
EXEC PGM=IEFBR14
//SYSUT1
DD DISP=(NEW,CATLG),DSN=TPIOA.START.SCHEDULE.D%%ODATE,
//
SPACE=(CYL,(5,1,50),RLSE),UNIT=GENUSER,
//
DCB=TPIOA.START.SCHEDULE
//*
//STEP20
EXEC PGM=IEBCOPY
//SYSIN
DD DUMMY
//SYSPRINT DD SYSOUT=*
//SYSUT1
DD DSN=TPIOA.START.SCHEDULE,DISP=SHR
//SYSUT2
DD DSN=TPIOA.START.SCHEDULE.D%%ODATE,DISP=SHR
//*
//STEP30
EXEC PGM=IEFBR14
//SYSUT1
DD DISP=(OLD,DELETE),
//
DSN=TPIOA.START.SCHEDULE.D%%DSNDEL
/*
Enterprise Services
Page 26
Printed 30/03/2014

4.3
JCL Library
All JCL that are executed by the Application within its Control-M
Production environment are done so from the following library:
TPIOA.application name.CNTL.D%%ODATE
When jobs are ordered into Control-M for processing, the D%
%ODATE value will be substituted to the current scheduling date of
Control-M.
For Example: if the current ODATE of Control-M is 940124, then the
JCL dataset when loaded into Control-M will be:
TPIOA.application name.CNTL.D940124
The above set-up allows the Operations Group to edit the JCL if
required but only affect the Current batch run of the application and
not any future runs.
Creation of the D%%ODATE JCL dataset
The TPIOA.application name.CNTL.D%%ODATE dataset must be
created at midday everyday as part of the New Day processing. When
the Application flows/jobs are initially set-up under Control-M a
Job/JCL (see below) must also be created to enable all JCL to be
copied from the Master JCL Library (TPIOA.application name.CNTL)
to the Odate JCL Library as described above.
To ensure consistency across Applications, the following is the
recommended naming standard for this JCL copy job:
QaaaCNTL
(where aaa = abbreviation of the application name)
//QaaaCNTL JOB acctcode,'CREATE JCL DSN'

//*
%%SET %%DSNDEL=%%CALCDATE %%ODATE -5
//CREATE
EXEC PGM=IEFBR14
//SYSUT1
DD DISP=(NEW,CATLG),
//
DSN=TPIOA.applname.CNTL.D%%ODATE,
//
SPACE=(CYL,(10,5,500),RSLE),UNIT=GENUSER,
//
DCB=TPIOA.applname.DCB
//*
//COPY
EXEC PGM=IEBCOPY
//SYSIN
DD
DUMMY
//SYSPRINT DD
SYSOUT=*
//SYSUT1
DD
DSN=TPIOA.applname.CNTL,DISP=SHR
//SYSUT2
DD
DSN=TPIOA.applname.CNTL.D%%ODATE,DISP=SHR
//*
//DELETE
EXEC PGM=IEFBR14
//SYSUT1
DD
DISP=(OLD,DELETE),
//
DSN=TPIOA.applname.CNTL.D%%DSNDEL
//*
An explanation of the JCL:

Enterprise Services
Page 27
Printed 30/03/2014

%%SET statement will give a value to the %%DSNDEL. In the

above example a value of 5 will be given. This means that the JCL
dataset will be kept for 5 days before the oldest generation is
deleted (by the DELETE step).
Step CREATE will create a new JCL dataset to be used for the
current processing day.
Step COPY will copy all JCL members
From: TPIOA.application name.CNTL
To:
TPIOA.application name.CNTL.D%%ODATE
Step DELETE will delete the JCL dataset that is 5 day old.
4.4
OVERRIDE Library
The Override library may be used to store and execute one off version
of current production JCL. The naming standard for this library is as
follows:
TPIOA.application name.OVRD
4.5
RUNBOOK Library
The naming standard for the Runbook Library is as follows:
TPIOA.application name.RUNBOOK
Enterprise Services
Page 28
Printed 30/03/2014

5.0 New Day Processing Standard

5.1
Application User Dailies

All Applications set-up to run under Control-M must have at least one
User Daily created for it.
The User Daily allows Application tables (jobflows) to be automatically
selected and loaded into the Control-M AJF at new day processing.
The standard is for a separate Control-M Table to be created for the
User Daily. The naming standard for this table is as follows:
USRDLYS
Within the above table individual User Daily members will be created
for the Application (in most cases one User Daily per application will
suffice). The naming standard is as follows:
UDaaaDLY
were: aaa = abbreviation of the application name/acronym
The following is a sample JCL for a User Daily:
//UDSTADLY JOB (IQCASQE000),'START USER DAILY',CLASS=H
//*
//* THIS USER DAILY WILL ORDER IN JOBS SCHEDULED
//* TO RUN FOR THE NEXT 24 HOUR PERIOD.
//*
//* DD DACHK POINTS TO THE MEMBER OF THE DATE RECORD.
//* THERE MUST BE ONE DATE RECORD MEMBER PER USER-DAILY.
//*
//* DD DAJOB(CONCATENATED) POINTS TO THE SCHEDULE TABLES.
//*
//PRD
EXEC CTMDAILY,DATEREC=UDSTADLY
//DAJOB
DD DISP=SHR,DSN=TPIOA.START.SCHEDULE(STAJCOPY)
//
DD DISP=SHR,DSN=TPIOA.START.SCHEDULE(STAALLDY)
//
DD DISP=SHR,DSN=TPIOA.START.SCHEDULE(STACALDR)
//
DD DISP=SHR,DSN=TPIOA.START.SCHEDULE(STADAILY)
/*
Note:
It is recommended that due to the critical nature of the User Daily, it is
set-up to generate a Problem Docket with a Severity of 3 for any
failures/abends.
Enterprise Services
Page 29
Printed 30/03/2014

5.2
Telstra Standard for New Day Processing

The current standard for Telstra Control-M New Day Processing is
from MIDDAY to MIDDAY.
Due to the above, the following consideration is to be noted:
Normal calendar days

00:00
31/10/95
1/11/95
11:59 12:00
23:59 00:00
1/11/ 95
ODATE days
2/11/95
23:59
11:59 12:00
2/11/95
The top box represent normal calendar days and the lower box
represent a Control-M ODATE day.
This means to have a job run at 20:00 1/11/95, it must be defined (within the
Control-M Calendar) as ODATE 20:00 1/11/95.
To have a job run at 08:00 2/11/95, it must be defined (within the Control-M
Calendar) as ODATE 08:00 1/11/95.
Enterprise Services
Page 30
Printed 30/03/2014

6.0 Control-M Utilities

6.1
Printing Job Flows

The following is a sample JCL to print a jobflow/table from an
Application Schedule library:
//IV00000A
//
//
//*
//STEP01
//DAJOB
//DAFLWPRM
JOB '00000000','PROD SUPP XXXXX',

MSGLEVEL=(1,1),MSGCLASS=X,
NOTIFY=IV00000,CLASS=A
EXEC CTMRFLW
DD
DISP=SHR,DSN=TPIOA.applicname.SCHEDULE(table name)
DD *
CHART YES
GROUP UNITED
PRINTER LASER
FONT 9
PAGESIZE 96
LINESIZE 176
PAGESEQ YES
/*
//STEP1.DAREPORT DD SYSOUT=A,DEST=T140DD11,HOLD=YES
//STEP1.DACHART DD SYSOUT=A,DEST=T140DD11,HOLD=YES
//STEP1.DACHART1 DD SYSOUT=A,DEST=T140DD11,HOLD=YES
//STEP1.DACHART4 DD SYSOUT=A,DEST=T140DD11,HOLD=YES
//STEP1.DACHART9 DD DSN=&&PRINT0,DISP=(NEW,PASS,DELETE),
//
SPACE=(CYL,40),UNIT=SYSDA,
//
DCB=(RECFM=FB,LRECL=180,BLKSIZE=4500,DSORG=PS)
//STEP1.PRTDBG
DD SYSOUT=A,DEST=T140DD11,HOLD=YES
/*
/*
//STEP2
EXEC PGM=KERIN1,COND=(0,LT)
//STEPLIB DD
DSN=IVPSUPP.CTMFLOW.LOAD,DISP=SHR
//FT05F001 DD DSN=&&PRINT0,DISP=(OLD,DELETE,DELETE)
//FT06F001 DD DSN=IVPSUPP.CTMFLOW.PRNTFILE,
//
DISP=(NEW,CATLG,DELETE),
//
SPACE=(TRK,40),UNIT=SYSDA,
//
DCB=(RECFM=FB,LRECL=180,BLKSIZE=4500,DSORG=PS)
//SYSPRINT DD SYSOUT=X,OUTLIM=20000
//SYSOUT
DD SYSOUT=X,OUTLIM=20000
/*
/*
//STEP3
EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=X
//SYSTSIN
DD *
VPSPRINT 'IVPSUPP.CTMFLOW.PRNTFILE' T140DD11 NONUM NOHDR CCHAR
/*
/*
//STEP4
EXEC PGM=IEFBR14,COND=EVEN
//DELETE DD DSN=IVPSUPP.CTMFLOW.PRNTFILE,DISP=(OLD,DELETE,DELETE)
/*
/*
//STEP5
EXEC PGM=IKJEFT01,COND=EVEN
//SYSTSPRT DD SYSOUT=X
//SYSTSIN
DD *
Enterprise Services
Page 31
Printed 30/03/2014

VPSPRINT 'IVPSUPP.CTMFLOW.CNTL(DONTDELE)' T140DD11 NONUM NOHDR CCHAR

/*
Copy of JCL available on VI2 IVPSUPP.CTMFLOW.CNTL(LASER)
Enterprise Services
Page 32
Printed 30/03/2014

6.2
MAYBE Utility
The MAYBE utility is useful for instances where particular job inconditions will not be satisfied for that processing day and therefore
needs to be added to allow the job/flow to run as per normal. This might
be applicable in instances whereby a daily job is dependant on a
monthly job that is only schedule to run on the last day of the month.
This utility will be set-up to run as two separate jobs. The first job
executing program IOALDNRS will scan the AJF and check all the
prerequisite conditions. If any of the following scenarios exists, the
condition will NOT be added when running this utility:
- condition is to be added by a DO COND statement,
- condition specified as an Out-Condition on any job currently in AJF,
- condition already exits in the conditions/resources file
If none of the above apply, the condition will be added to the Manual
Condition File.
The following is a sample JCL for the IOALDNRS utility:
//QCIMLOAD JOB QPCIM199,'CONTROLM UTILITY,
//
CLASS=H,MSGCLASS=4,REGION=0M
/*XEQ VI2
//*
//* THIS JOB SCANS EVERY JOB IN THE AJF. ALL PREREQUISITE
//* CONDITIONS ARE CHECKED. IF THE IN CONDITION IS ADDED
//* BY EITHER A 'DO COND' STATEMENT OR AN OUT PARAMETER,
//* OR ALREADY EXISTS IN THE CONDITIONS/RESOURCES FILE,
//* THE CONDITION IS IGNORED. IF NOT,THE CONDITION IS LOADED
//* INTO THE MANUAL CONDITIONS FILE. THIS JOB WILL ALSO
//* IGNORE CONDITIONS SPECIFIED WITH THE PREFIX GIVEN IN
//* THE IGNORE STATEMENT BELOW. IF ADDMODE IS SPECIFIED,
//* THE EXISTING MANUAL CONDITIONS LIST IS NOT DESTROYED.
//*
//STEP1
EXEC IOALDNRS
//DALNRIN DD *
IGNORE IN CONFIRM
IGNORE IN HYP
CONTROLM YES
ADDMODE
/*
Notes:
1. The IGNORE statement mentioned in the JCL will exclude any
conditions (ie. In-Conditions) beginning with CONFIRM and HYP.
A number of ignore statements can be specified depending on the
Applications requirements.
2. It is important to note that this utility will scan the conditions of
EVERY jobs/applications currently in the AJF.
Enterprise Services
Page 33
Printed 30/03/2014

The second jobs will check the manual condition file and add any
conditions with the specified prefix (in the example below
QCIM..) to the conditions & resource file. By so doing this will
achieve the end result of satisfying those conditions that will not be
met for that processing day.
The following is the sample JCL to perform the above:
//QCIMPOST JOB QPCIM199,CONTROLM UTILITY,
//
CLASS=H,MSGCLASS=4
/*XEQ VI2
//
EXEC CTMRKSL
*--------------------------------------------------------------*
*
FUNCTION:
*
*
UTILITY TO ADD A MANUAL CONDITION IN SCREEN 7.
*
*
*
*
BEFORE OPERATING THIS KSL, SCREEN 7 PERHAPS SHOULD
*
*
BE RE-FRESHED VIA UTILITY CTMLDNRS.
*
*
*
*
THIS CAN BE USED TO HANDLE 'MAY-BE JOBS' WITH
*
*
'MAY-BE CONDITIONS'. FOR ADDITIONAL INFORMATION
*
*
PLEASE REFER TO THE MANUAL.
*
*
*
*
ARGUMENT:
*
*
A1 PREFIX
PREFIX OF CONDITION(S) TO BE ADDED
*
*
A2 DATE
(DDMM), OR 'NULL' FOR ANY DATE
*
*
*
*
*
*--------------------------------------------------------------*
TRACE OFF
MAXCOMMAND 999999
CALLMEM SCRSET
CALLMEM ADDCOND7 QCIM NULL
END
Where desired or necessary, the above utility may be set-up to add

conditions for the current or specific ODATE. In which case, the
following coding will apply:
*
*
*---------------------------------------------------------------------*
TRACE OFF
MAXCOMMAND 999999
CALLMEM SCRSET
CALLMEM ADDCOND7 QCIM %%ODAY.%%OMONTH
CALLMEM ADDCOND7 QCIM %%CYCL%%ODAY.%%OMONTH (If running Cycles eg Fcabs)
END
***** NOTE VERY IMPORTANT *****

It is MANDATORY to specify the Application jobname prefix in this
utility (in the above example QCIM). Failure to do so will cause
conditions belonging to other Applications to be satisfied and jobs to
be prematurely started. Therefore, GREAT CARE must be taken when
using this option. If in doubt consult one of the Application
Management Team Leaders.
Enterprise Services
Page 34
Printed 30/03/2014

7.0 Appendix A
Sample 'REQUEST FOR CONTROL-M ACCESS' Form
REQUEST FOR CONTROL-M ACCESS FOR PRODUCTION.

This section is to be completed and actioned by applicant.
APPLICANTS NAME : ______________________________________

APPLICATION NAME :
.
or
OIM ASSIGNMENT NAME :
.
HOST/DOMAIN APPLICATION RESIDES ON :
CONTROL-M HOST :
.
.
CONTROL-M BATCH USERID HAS BEEN CREATED FOR USE ON THE

FOLLOWING DOMAINS :
(Please indicate domains explicitly or type ALL for all domains)
LPAR/S : ____________________________________________________________
DEFAULT RACF GROUP :
CONTROL-M BATCH USERID :
APPLICATION SUPPORTED BY CPS ?

indicate (Y/N) : ___
Completed by:
________________________________
/
/
.
please
Contact No. ________________
On
** Only send this form AFTER the Controlm batch userid has been created. **
** Please email this form to David J Timms, System Management. ph (03) 9253-7151. **
This section is to be completed and actioned by System Management.
FCTMUapp, FCTMRapp, FCTMNapp
app = __ __
__ ?
** Please email this form to System Security. **
This section is to be completed and actioned by System Security.
CTM RACF access groups created ?

CREATE SURROGAT CLASS PROFILE:
please
userid.SUBMIT
please
PERMIT STC USERID TO READ SURROGAT CLASS PROFILE

please
FACILITY CLASS PROFILES CREATED ?

please
PERMIT CTM ACCESS GROUPS TO FACILITY CLASS PROFILES ? please

Enterprise Services
Page 35
Printed 30/03/2014

PERMIT SYS3 DATASET PROFILES ?

please
SETR REFR RAC(FACI) command issued ?

please
Completed by:
________________________________
/
/
.
Contact No. ________________
On
** Please return to System Management when this section completed. **

This section is to be completed and actioned by System Management.
CONTROL-M DATASETS TO BE CREATED :

TPIOA.
.SCHEDULE
TPIOA.
.CNTL
TPIOA.
.OVRD
TPIOA.
.RUNBOOK
RACF DATASET PROFILES CREATED:

please
PERMISSION'S TO RACF D/S PROFILES GRANTED :

please
DATASETS CREATED :
please
CONNECT USERID TO GROUP FCTMAPS or FCTMTSP

please
Completed by: ________________________________

Contact No. ________________ On
/
/
.
** If the userid was created for an application, please email this form to Production Support applicant. **
Archive hardcopy in processed forms file.
G:\ISM\CONTROLM\CTRMFORM.DOC
Enterprise Services
This form :
Page 36
Printed 30/03/2014

CTLM STD

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

CTLM STD

Caricato da

Copyright:

Formati disponibili

IBM Global Services Australia

MVS Production Support

a joint venture with Lend Lease and Telstra

Production CONTROL-M Standards

IBM Global Services Australia

PRODUCTION MANAGEMENT GROUP

Document Owner: Production Management

This document contains proprietary information. ALL INFORMATION CONTAINED

IBM Global Services Australia

a joint venture with Lend Lease and Telstra

Production CONTROL-M Standards

IBM Global Services Australia

a joint venture with Lend Lease and Telstra

Production CONTROL-M Standards

IBM Global Services Australia

a joint venture with Lend Lease and Telstra

Production CONTROL-M Standards

1.2 Creation of Control-M Production Batch USERID

1.3 Format of Control-M Production Batch USERID

IBM Global Services Australia

a joint venture with Lend Lease and Telstra

Production CONTROL-M Standards

2.0 Job Scheduling Definitions Standard

IBM Global Services Australia

a joint venture with Lend Lease and Telstra

Production CONTROL-M Standards

In the above JCL at run time the value %%SYMVARXX will

IBM Global Services Australia

a joint venture with Lend Lease and Telstra

Production CONTROL-M Standards

One of the main advantages the above offer is the ability to

IBM Global Services Australia

a joint venture with Lend Lease and Telstra

Production CONTROL-M Standards

2.2 Calendar Scheduling Criterias Definitions

CONFCAL TIPFRIMN SHIFT

DAYS, WDAYS, DCAL, WCAL & CONFCAL

IBM Global Services Australia

a joint venture with Lend Lease and Telstra

Production CONTROL-M Standards

IBM Global Services Australia

a joint venture with Lend Lease and Telstra

Production CONTROL-M Standards

2.3 IN-CONDITION Definitions

IBM Global Services Australia

a joint venture with Lend Lease and Telstra

Production CONTROL-M Standards

date and month of schedule date.

Important: when using the PREV option, BOTH the job

IBM Global Services Australia

a joint venture with Lend Lease and Telstra

Production CONTROL-M Standards

2.4 OUT-CONDITION Definitions

2.5 F.Y.I Housekeeping of Condition & Resource File

2.6 RESOURCE Definitions (Quantitative & Control)

Both the Quantitative and Control resources must include the

IBM Global Services Australia

a joint venture with Lend Lease and Telstra

Production CONTROL-M Standards

2.7 Run TIME Definitions

2.9 Automatic Restart

IBM Global Services Australia