CA-7
&
CA-11
D:\533579581.doc
CA-7 / CA-11 CLASS OUTLINE
WHAT IS CA-7 ................................................................................................................................... PAGE 1
DEFINE SOME TERMS
- JOB TRIGGERING
- JOB DEPENDENCY
- FORCE COMPLETE
- CANCEL
HOW JOBS ARE SCHEDULED .................................................................................................. PAGE 2 - 3
- CALENDAR SCHEDULE
- TRIGGERED
JOB REQUIREMENTS ...................................................................................................................... PAGE 4
- SUBMIT TIME
- USER REQUIREMENT
- JOB DEPENDENCY
SIGN-ON TO CA-7 (THREE WAYS) ........................................................................................... PAGE 5
- CA7CLIST FROM TSO COMMAND LINE
- CA OPTION FROM YOUR SPF MENU THEN SELECT 7
- CA7ONL SELECTION ON TPX
ENTER SOME LIST COMMANDS
...................................................................................... PAGE 6 - 7
- LJOB (LISTS SCHEDULES, TRIGGERS, REQUIREMENTS FOR A JOB)
- LACT (LIST ALL JOBS CURRENTLY ACTIVE ON CA7)
- FSTRUC (LISTS THE FLOW OF A JOBSTREAM)
- LSCHD (CALENDAR LIST OF WHEN A JOB RUNS)
- LPRRN (LISTS THE LAST TIME A JOB COMPLETED)
#JI / #JEND CONTROL CARDS .................................................................................................. PAGE 8
-ALLOWS DIFFERENT VERSIONS OF JCL TO RUN FROM A SINGLE MEMBER
WHAT IS CA-11 ................................................................................................................................. PAGE 9
- DIRECTS CA-7 WHICH STEP TO RESTART A JOB IN
- PERFORMS DATASET AND GDG MAINTENANCE
- D50W200S - REPORT OF ALL ACTIVITY PROCESSED IN CA-11
CA-7 RESTART SCREEN (CA-11 MAKES RESTARTS SIMPLER )
CA-7 JOBSCREEN - FIELD TO ACTIVATE CA-11 .................................................................... PAGE 10
USING CA-11 TO INCORPORATE RESTORE JCL INTO YOUR JOB ................................ PAGE 11 - 16
STEPS TO FOLLOW:
- ENTER RESTORE STEPS INTO JCL
- ADD CONDITION CODE CHECKING TO JCL (JOBCARD & RESTORE STEP)
- ADD #SCC STATEMENTS TO ALLOW CA-7 TO ACCEPT RC OTHER THAN 0 (PRODSUPP
DOES)
- UPDATE CA-7 JOBSCREEN TO ACCEPT #SCC (PRODSUPP DOES)
- DOCUMENT RESTART INSTRUCTIONS
- IF MORE THAN ONE SET OF RESTORE STEPS, NEED TO USE A DIFFERENT CONDITION
CODE
FORCE CA07RMS STEP TO RECEIVE A RC OTHER THAN 0
(PRODSUPP DOES)
D:\533579581.doc
CA-11 CONSIDERATIONS WHEN CODING JCL ........................................................................ PAGE 17
- UNIQUE JOBNAMES
- UNIQUE STEPNAMES
- UNIQUE NON-GDG DATASET NAMES
- CATALOG DATASETS WHEN POSSIBLE
- ALWAYS CODE THE DISPOSITION PARAMETER
CA-7 HELPFUL HINTS ................................................................................................................... PAGE 18
- SOME OF THESE HINTS WILL BE MORE USEFUL WHEN YOU GAIN MORE EXPERIENCE
D:\533579581.doc
CA-7
CA-7 is our automated job scheduler. Jobs can be scheduled to run and manipulated in a variety of ways.
Two common terms that have caused confusion are "job triggering" and "job dependency."
Job triggering means a job's JCL is being pulled into the CA-7 queue for execution. If it has no other
dependencies on it, it runs right away. But if there are other dependencies, it will wait for them to be satisfied. In
other works, when a job is triggered, it doesn't necessarily run right then.
A job dependency is a job that must complete before the job waiting in the queue can run. Upon successful
completion of the preceding job, the job waiting in the queue will be submitted. However, if the dependent job does
not complete successfully, the job dependency will not be posted.
Also, the terms "force complete" and "cancel" both mean to remove a job form the CA-7 queue. But the
results are completely different.
A job is forced complete when it returns an acceptable condition code, or when it does not require an immediate
remedy, and the job stream can continue. Forcing a job complete tells CA-7 to treat the job as having completed
successfully, and to continue processing. Any dependencies of this job on other jobs will be posted, and any job
triggering by this job will be done.
Canceling a job from the queue does just the opposite. The job will be removed from the CA-7 queue, but
no job triggering will be done, and any dependencies of this job on others will not be posted. This command is used
to stop a job stream.
Page-1
D:\533579581.doc
CA -7 SCHEDULING
Jobs can be scheduled in two different ways:
1) Calendar scheduled
2) Triggered
Calendar scheduled means a job has been added to one of the CA-7 calendars for a specific day(s) and time
Page-2
D:\533579581.doc
CA-7 SCHEDULING
Triggered means job 'B' will only run when job 'A' triggers it in.
Page-3
D:\533579581.doc
Jobs can have 3 different dependencies:
1) Submit time
2) User requirement
3) Job dependency
Jobs can be scheduled using any or all of the above methods.
Submit time means that at its set time, the job will automatically be submitted by CA-7, provided any other
dependencies have been met.
Job dependencies are posted by completion of preceding jobs. All jobs are set up with a "look back" time.
That determines how far CA-7 will look back to see if the proceeding jobs completed successfully during that
timeframe.
User requirements are text messages that need to be manually posted for the job to be submitted.
Page-4
D:\533579581.doc
ACCESSING CA-7
There are 3 different ways to access CA-7.
1) TSO CA7CLIST from the command line on nearly any TSO screen.
2) Select the CA option at the SPF PRIMARY OPTION MENU. From there, select 7 at the CA
PRODUCT SYSTEM MENU.
3) CA7ONL option from the TPX menu.
Option 1:
Option 2:
Option 3
Page-5
D:\533579581.doc
LJOB, LIST=NODD, JOB=jobname
This command will display what job this one is triggered by, what jobs it will trigger, what jobs are dependent on
this job, and dependencies for this job (jdeps and user requirements).
Page-6
D:\533579581.doc
HELPFUL DISPLAYS
1) LACT, SEQ=JOB
All jobs currently active through CA-7.
2) FSTRUC, JOB=JOBA, SCHID=1
All jobs triggered by JOBA, and all subsequent jobs
triggered by those.
3) LSCHD, LIST=BYSID, JOB=JOBA
This command is only valid on jobs set up on a calendar
schedule. It gives a calendar listing of what dates the job
will run in the current year in schedule ID order.
4) LSCHD, LIST=CALS, JOB=JOBA
Same as the above, but all schedule ID's are included in
one annual listing.
5) LPRRN, JOB=JOBA
Displays the last time JOBA completed successfully.
Page-7
D:\533579581.doc
#JI / #JEND CONTROL CARDS
Running a job under multiple schedule ID's allows us to run different versions of JCL from a single member.
SYNTAX:
#JI,ID=XXX
XXX=schid of the job in which this JCL should be used.
//JCL to be executed when that schid runs
#JEND
designates the end of the JCL to be run on this schid.
Page-8
D:\533579581.doc
CA-11
CA-11 is our rerun management package. Its 2 main functions are:
1) Directs CA-7, which step to restart the job in, no restart parm needed.
2) Performs data set and GDG maintenance.
CA-11 inserts a step at the beginning of the job called CA07RMS. Within this step, CA-11 scans the JCL
being run and looks for any data sets being created in the job. If the first instance of a file in the job has a
disposition beginning with "NEW," CA-11 then checks the system catalog to see if there is already an existing data
set by that name. If there is, CA-11 then deletes it to prevent a NOT CAT 2 error. THIS HAPPENS WHETHER IT
IS A PRODUCTION RUN OF THE JOB, OR A RESTART.
Also, if necessary, GDG adjustments are made by CA-11 in this step. Any changes to bias numbers, (+1)
to (0) on a restart, for example, are done by CA-11.
All activity processed through CA-11 is logged to a data set called the JEHF (job execution history file).
On Sunday nights, a tracking job is run against that file. This job creates a report showing all jobs that were
restarted through CA-11 during the previous 7 days, and their ABEND codes. The report is available in SAR under
the jobname, D50W200S
Page-9
D:\533579581.doc
Page-10
D:\533579581.doc
In the event that an abended job would require a separate restore job to run before restarting, CA-11 can be
used to incorporate restore JCL right into your regularly scheduled productions jobs.
Utilizing the CA-7 restart options, the CA-11 step can be forced to return a predetermined condition code.
The restore steps are then coded so they will only execute when the job is restarted with that specific condition code.
We mainly use "03" as the condition code for jobs running in this manner, since that is not a normal return
code, and there is no chance of this step getting that code unless you specify it.
Using this option will enable you to eliminate many of the steps involved in restarting jobs that require
restores before the restart. Here are the guidelines for using this handy feature of CA-11.
Page-11
D:\533579581.doc
Page-12
D:\533579581.doc
1) Enter the restore step(s) into the production job immediately before the step that requires the restore to run
before restarting. Be sure the restore steps being copied or entered in are numbered logically for easy reference.
Also be sure no step names are duplicated.
------------------------------------------------------------------------------------------------ -----------------//G60N043W
//
//
//
//
//
JOB 'PROD-7753-PC'
'BUILD FORM FILES',
MSGLEVEL=(1,1)
MSGCLASS=G
CLASS=1, REGION=4096K.
COND=(3,LT)
2) Place a condition parm of (3,LT) on the jobcard. This will only allow steps with a condition code of 3 or less in
the job. NOTE: CONDITION PARAMETERS CODED ON THE JOBCARD ARE CHECKED BEFORE
PARMS CODED ON THE INDIVIDUAL STEPS. FOR THAT REASON, GREAT CARE MUST BE TAKEN TO
INSURE THE CONDITION CODING YOU CHOOSE WILL EXECUTE ALL STEPS PROPERLY
---------------------------------------------------------------------------------------------------------------------------------------- -
3) Condition code the restore steps (3, NE, CA07RMS.RMS@20). This will ensure that these steps will only run
when the CA-11 step is forced to return a condition code 03. In a normal successful run of the job, these steps
will flush.
Page-13
D:\533579581.doc
//G60N014W
JOB 'PROD-7735-PC',
//
'BUILD FORM FILES',
//
MSGLEVEL=(1,1),
//
MSGCLASS=G,
//
CLASS=1,REGION=4096K
# SCC,COND=(3,LT,RMS@20)
# SCC,COND=(0,NE,*-RMS@20)
4) Add 2 #SCC statements to the JCL immediately after the jobcard. They are #SCC,COND=(3,LT,RMS@20)
and #SCC,COND=(0,NE,*-RMS@20). The first statement tells CA-7 to pass a condition code of 03 or less in
the CA07RMS step as acceptable and not flag the job as abended. The second tells CA-7 not to accept any
condition code other than 00 in all other steps.
----------------------------------------------------------------------------------------------------------------------------- ------------
5) The CA-7 JOB screen must be set. The RO field should be #S. This tells CA-7 to read the #SCC entries added
after the jobcard. Those entries dictate which condition codes are acceptable, if any, and not to flag the job as
abended on these condition codes. ALSO, the job must be running through CA-11 to use this function, so the
INSERT-RMS field must be set to Y
Page-14
D:\533579581.doc
//****************************************************************************
//* STEP020 - USE INPUTED RELEASED COMPANIES TO BUILD CERT FILE
//*
//* STEP
|
RESTART
|
SPECIAL INSTRUCTIONS
//* ----------------------------------------------------------------------------------------------------------------//* STEP020
|
STEP012
|
RESTART IN STEP012 THROUGH
//*
|
|
CA-11 AND FORCE THE CA-11
//*
|
|
STEP TO RETURN A CONDITION
//*
|
|
CODE 03.
//****************************************************************************
//STEP020
EXEC PGM=UWNCFC02,
//
COND=(3,LT)
//IUWNCF02
DD
DSN=G60.PROD.NEWCASE.SORT,
//
DISP=SHR
//OUWNCF02 DD
DSN=G60.PROD.NEWCASE,CERT,
//
DISP=(NEW,CATLG,DELETE),
//
UNIT=DISK,
//
SPACE=(TRK,(8,2),RLSE)
//*
----------------------------------------------------------------------------------------------------------------------------- ----------//*
//****************************************************************************
//* STEP012 - USE RELEASED COMPANIES TO REBUILD CERT FILES
//*
//* STEP
|
RESTART
|
SPECIAL INSTRUCTIONS
//* -----------------------------------------------------------------------------------------------------------------// STEP012
|
STEP012
|
THIS STEP WILL ONLY EXECUTE
//
|
|
ON A RESTART OF A STEP020
//
|
|
ABEND. FORCE THE CA-11 STEP
//
|
|
TO RETURN A CONDITION
//
|
|
CODE 03.
//****************************************************************************
//STEP012
EXEC
PGM=UWNCFC04,
//
COND=(3.NE.CA07RMS.RMS@20)
//IUWNCFR1
DD
DSN=G60.PROD.NEWCASE.CERT,
//
DISP=SHR
//OUWNCFR2 DD
DSN=G60.PROD.CMPY.SORT,
//
DISP=(NEW,CATLG,DELETE),
//
UNIT=DISK
//
SPACE=(TRK,(8,2),RLSE)
6) The documentation for the step requiring the restore should state the restart step (the first restore step) and
instructions to force the CA-11 step to get a condition code 03. ALSO, in the event one of the restore steps
would ABEND, to be restarted, the CA-11 step must again be marked to return a code 03, or the steps will
flush. It is good for this to be mentioned in the documentation of the restore steps as well.
7) As always, there are exceptions to the rule. If you use more than 1 set of restore steps in a single job, be sure to
use different condition codes. For example, code 1 set of restore steps to run if the CA07RMS step returns a
condition code 03. But code the other set of restore steps to run if the CA07RMS step returns a condition code
01. Since 01 is less than 03, the remaining steps coded (3,LT) will still execute.
Page-15
D:\533579581.doc
CA-11 CONSIDERATIONS WHEN CODING JCL

UNIQUE JOB NAMES.
MVS does not allow concurrent execution of more than 1 job of the same name. Also, in CA-11, only 1
CMT member may exist under each name.

UNIQUE STEP NAMES.
CA-11 restarts are performed by the specific step name. If a job abends, and there is more than 1 step by
that name, CA-11 will restart the job in the first step of that name. If this occurs and is not discovered until after the
job has run and abended, it cannot restart through CA-11, since steps cannot be deleted and step names cannot be
changed.

USE GDG'S WHENEVER POSSIBLE
Using a generation data group (GDG) allows several generations of a backup under the same data set name.
When rerunning/restarting a job, all GDG adjustments are made by CA-11.

UNIQUE NON-GDG DATASET NAMES
Unique non-GDG data set names reduce the risk of using an incorrect file. And since CA-11 will attempt
to uncatalog and/or delete any file being newly created, it may remove data set of the same name that is referenced
again in a subsequent step or job.

CATALOG DATASETS WHEN POSSIBLE
Avoid using temporary (&&TEMP) files. Create new data sets using a disposition of (NEW, CATLG,
DELETE), then delete them with an IEFBR14 after they are last used. MVS deletes any data set with a &&TEMP
name when the job ends, leaving that step non-restartable, as the necessary files no longer exist.

ALWAYS CODE THE DISPOSITION PARAMETER
If a disposition is not specified, the MVS system assigns it a default disposition of (NEW, DELETE,
DELETE). In order to prevent NOT CAT 2 errors, CA-11 will uncatalog and/or delete any non-GDG data whose
first occurrence of disposition begins with NEW. With (NEW, DELETE, DELETE) you will lose a data set you
may have wanted to catalog or keep.
Page-16
D:\533579581.doc
CA/7 Helpful Commands
Here are some PF keys and commands that were found helpful for CA/7. There are different ways to access CA/7.
These PF keys will only work when accessing CA/7 as a main option off your TPX screen (See Page 5, Option
3). If you access CA/7 through TSO, the PF keys will not be recognized.
PF Key
PF 7 & Shift
PF 9
PF 1
PF12
PF 4
PF 2
PF 10
Description
The FSTRUC command. If you list the trigger job it will list all jobs in that structure
The LJOB command. Lists items such as which schedule the job is on, if the job is
executable, job requirements, dependencies, triggers, etc.
Active jobs
Jobs waiting to be submitted. They have some type of dependency on them. The
dependency can be a job dependency, a time dependency, or a user requirement.
Another view of PF 12. This view gives you the actual dependencies that the job is
waiting for. If you want to just see your particular job instead of all jobs, at the end of
the pf4 command, type ‘,job=jobname’
Jobs waiting that are already submitted. All dependencies have been met and the job is
just waiting to be run. The jobs will go from the PF12/PF4 screen to this screen.
Jobs in abended status
A couple more helpful hints:
Jobs running from the override library (one shot only)
Use the PF 9 key and look for a line after the “LAST MAINTENANCE LINE”. You should see a line that reads
“JCL SET FOR RETRIEVAL FROM OVERRIDE LIBRARY FOR NEXT RUN”. This line gets removed as soon
as the job hits the queue (meaning it will be in the pf2, pf4/pf12 screen).
Non-executable jobs
Use the PF9 key. Look for a flag called “JCL SET FOR EXEC ON MAIN”.
Y= EXECUTABLE
N=NON-EXECUTABLE
This change requires someone to physical go into a screen and change the flag back and forth. So when you make a
change to the schedule to make a job either executable or non-executable, you can go out and verify that the change
was made by looking at this field.
Page-17
D:\533579581.doc