Está en la página 1de 9

Q. What is CA-7 Scheduler? Where did CA-7 come from?

Think of jobs as, Flights taking off from an Airport. On a busy airport, when the
clock strikes 09:00 AM, all jobs that were scheduled to depart at 09:00 AM take-
off. CA-7 Scheduler manages and oversees all of this.

In the Production Environment(where things are running live), you don’t type SUB on
a Production Job and give it to the Mainframe Computer for Processing. Production
Jobs are generally scheduled – they auto-start at a given time. The CA-7 Scheduler
on Mainframes maintains a periodic Time-table, a database or chart of which jobs
run when?

A company had made CA-7 in the United States for their own internal use, under the
name SASS. You would still see programs like SASSBSTR and SASS Messages today.
Universal Computing Company(UCC) bought the product SASS and renamed it UCC-7. In
1987, Computer Associates(CA) bought UCC, and it was their policy to name all their
products with CA Prefix, so UCC-7 became CA-7.
Q. What is the CA-7 Queueing System?
CA-7 has different staging areas called Queues, where jobs could be. The CA-7
Queues are the (1) Request Queue (2) Ready Queue and (3) Active Queue. These queues
are like traffic signals on a road. First the job has got to wait in the Request
Queue(Red Signal). Next, the job has to wait in the Ready Queue(Orange Signal) –
this means the job is almost ready to run. When the job is currently running, we
say its in the Active Queue(Green Signal).

(1) The Database holds the Timetable of when the jobs run. CA-7 periodically scans
the database(timetable) for which jobs are likely to run in the next few minutes.

(2) When the clock strikes 09:00 HRS, the Job A enters into the Request Queue. The
JCL of the Job is picked up from the JCL Library and added to the Trailer of the
CA-7 Request. Each Job in the Request Queue, waits for certain requirements to met.

(3) When all conditions and requirements are met, the job progresses ahead to the
WLB(Workload Balancing).

(4) When there are enough initiators to pick up the Job from the Queue, the job is
sent to the JES2. While a job is on WLB or JES2, its shown on the
Ready Queue.

(5) An SMF Type 20 or 30 record(job initialization) is received by CA-7, and the
job is moved to the Active Queue, and will start execution in an address space.

(6) The job will remain on the Active Queue, until an SMF Type 5 or 30(job
completion) is received by CA-7. On receipt of the job completion, if the job is
successful, the Prior Run Queue(PRRN) Queue will be updated with the details of the
execution. This serves as a last run-time record for the job. However, if the job
fails, it will be returned to the Request Queue(REQ).
Q. How a job enters into the Request(REQ) Queue?
There are 3 ways, a job can enter into the Request Queue[REQ]. A job can be
Scheduled, triggered or demanded out.

(1) Scheduled(SSCN) – Jobs can be scheduled to run at a fixed time – for example,
Reporting job runs every month-end at 08:00 PM, Load jobs run every-day at 05:00 AM
and so on.

(2) Triggered(AUTO) – A parent job X, when it runs to successful completion, can
TRIGGER another child job Y. A TRIGGER automatically brings Job Y into the REQ

(3) Demanded(DEMD) – A Job X can programmatically Demand out another Job Y. For
Job X has the following code :

If Input File contains DATA
Demand Job Y

Here, Job Y is brought into the Request Queue[REQ], only if the Input-file has data
records. If the Input file is empty; if there’s no data to process, the job is not
demanded out. So, in this fashion, you can exercise more control, over how the job
kicks off.
Q. How to know Job’s information in CA-7?
You type the command LJOB,JOB=jobname,LIST=ALL to find all the information about a
job. Look at how I’ve found all the information about my job GEMPAIAS on CA-7.

This shows all the information about my job CPARSDLY – which jobs does it trigger,
which are the successor jobs, what are the steps in this job etc.

To know, if a job is Scheduled, or Triggered or Demanded out, the CA-7 Commands are
Scheduled – LSCHD,JOB=jobname,LIST=CALS
Triggered – LJOB,JOB=jobname,LIST=TRIG
Demanded – Unfortunately, there’s no direct way no this, as Demand Information is
not stored in CA-7, but in JCL. However, if the Job is demanded out into the REQ
Queue, it shows up as DEMD in the Entry Mode column. Sometimes, you can use
LJOB,JOB=jobname,LIST=PROS option of the LJOB Command to find out information about
the Demanding job.
Q. How to know, if a job is scheduled?
The quick way to know if a Job is Scheduled, is to use the List Schedule[LSCHD]
Command, with LIST=CALS(Calendar) option. This opens up a Calendar view, and tells
us, what time and on what calendar days of the year, your job is going to run.

In the clipping below, my job GMSBDRQ1 runs on all week-days, Monday-to-Friday at
23:00 hrs.
Q. How to know, if a job is triggered?
A job X can be brought in the REQ(Request) Queue, when it is triggered by
Job Y. How do you know, the Triggering Job or Parent Job. You can code
LIST=TRIG(Triggers) option on the LJOB Command, to find out the
triggering job. In the below clipping, my job XRPDGLPS is triggered by the parent
job GMSBDRQ1. When GMSBDRQ1 completes, my job XRPDGLPS would be brought into the
REQ(Request) Queue.
Q. How to know if a Job is Demanded out?
A job can be programmatically demanded out by another job, based on given
condition. If the condition is true, the job is demanded out into the REQ(Request)
Queue. If the condition is false, the job is not demanded out. Generally,
information about the Demanding job is not stored in CA-7. Sometimes, the
LIST=PROSE option of the LJOB command, may give details about the Demanding job. In
the below clipping, my job GEMIATAL job is demanded out by GMLIASXA.
Q. How long does a job wait in REQ Queue, before it enters RDY Queue?
A job has to wait in the CA-7 REQ(Request) Queue, until all of the requirements it
has are satisfied. Requirements are like additional promises, which must be
fulfilled, before a job is allowed to run. Requirements could be anything like,
Completion of another job, Arrival(creation) of a file(Dataset), Submit Time, User
Hold or a Negative Dependency. Its only when all the Requirements, of a job are
fulfilled or posted, the job is brought to the Ready Queue(RDY).

Check out this example. A Job X triggers Job Y. Job X completes everyday at 08:00
AM. Job Y has 2 requirements – R1 and R2. Job R1 completes at 07:00 AM and Job R2
completes at 09:00 AM. The question is, when does Job Y kick-off? I would say, when
Job X completes at 08:00 AM, it triggers Job Y, so it brought to the Request Queue
at 08:00 AM. The requirement R1 of Job Y is satisfied, but it will wait in Request
Queue[REQ], till R2 is satisfied. When R2 completes at 09:00 AM, both the
requirements are satisfied, and Job Y will be brought to the Ready Queue[RDY].
Q. What are predecessors and successors of a Job?
Think of a relay-race with three participants – Arnold, Danny and Carol. The three
participants are scheduled to start running, but spaced apart in intervals of 15
minutes each. Arnold is scheduled to start running when the timer is 00:00 hrs.
Danny is scheduled to start running when the time is 00:15 Hrs. Carol is scheduled
to start running, when the time is 00:30 Hrs.

Requirement of Danny – Danny is allowed to start running, only after Arnold
completes the race, and passes on the baton to him.

Dependent Carol – Danny owes a favour to Carol, he has a commitment towards her. He
must complete the race and pass on the baton to her, before she can start off.

Arnold –> Danny –> Carol

Danny’s predecessor is Arnold. Danny’s successor(dependent) is Carol.

You can use the LIST=RQMT option on LJOB Command, to find out the requirements or
predecessors of a job. You use the LIST=DEPJ option on the LJOB Command, to find
the successors of a job.

In the above video clipping, my job GEMTOPR3 has the requirement
(pred job) AXMYTOPV. When GEMTOPR3 enters into CA-7 REQ(Request) Queue, its gonna
wait for the Requirement AXMYTOPV to be satisfied. Only, when the requirements are
met, my job GEMTOPR3 can enter into RDY(Ready) Queue. Moreover, the jobs GEMCNSTL,
GMCNTODL and QRPDR3PA are the successors of GEMTOPR3. This implies that the jobs
GEMCNSTL, GEMCNTODL and QRPDR3PA have my job GEMTOPR3 as a requirement.

Predecessor job-names may be preceded by a slash(/) to indicate
Negative dependency. A conditional Dependency is indicated by prefixing the
predecessor job-name with a question-mark(?). If a job A is conditionally dependent
on Job B, then Job A will have dependency(requirement) on Job B, only if Job B is
in the REQ(Request) Queue, RDY(Ready) Queue or ACT(Active) Queue. The dependency is
conditionally applied, provided the pred-job is in
CA-7 Queue.
Q. What is Lead Time? What are Look-back issues?
Lead Time is the period(in hours)[time-window], that a job looks back in time, to
check if all its requirements(promises) are fulfilled. See the below example. Here,
my job GEMPAIAS has a requirement on PZCPDWKY, with a Lead Time of 5 hours.

Suppose, my job GEMPAIAS is a scheduled job, it is scanned out everyday, and enters
the REQ(Request) Queue at 07:00 AM in the mornings. Now, the GEM* Job is going to
check for its requirement of Pee-zee(PZ*) job. Has the Pee-Zee(PZ*) Job completed
in the last 5 hours? Thus, the GEM* Job searches for its requirement Pee-Zee(PZ*)
job’s completion in the time-window of 02:00 AM to 07:00 AM. If the Pee-Zee(PZ*)
Job would have completed in the time-frame[02:00-07:00 AM], the requirement is

However, if the Pee-Zee(PZ*) Job completes, say at 00:00 Hrs, this doesn’t fall in
the time-window 02:00-07:00 AM, so the requirement shall not be satisfied. The GEM*
Job merely keeps waiting in REQ(Request) Queue(even though the PZ* Job ran, but ran
at 00:00 Hrs). This is a classic example of a Look-back Issue.

Very often, there is too large a time-gap that elapses between a predecessor job
A's completion, and its dependent B's starting out. When B is brought into the
REQ(Request) Queue, if A's completion doesn’t fall in the Look-back(Lead-time)
window, B keeps waiting in the REQ Queue. These are called Look-back Issues. CA-7
Look-back issues generally happen in the Production Environment, generally due to
delays in Batch Cycle, holidays etc.

Lead-Time could take several values.

00 – No special consideration for the amount of time elapsed, between the pred-job
and dependent job's runs.
99 – The requirement is never to be considered as already satisfied, when the job
enters the Queue.
nn – Since, the last run of the job, each predecessor job must have run within the
last nn hours. Values for nn may be from 1 to 98.
Q. What is a Negative Dependency?
Sometimes, you wish - I hope these two jobs don't collide, don't run at the same
time. If a Job P has a Negative Dependency N, Job P and Job N can't run
together(mutually exclusive). So there are 2 possibilities -

1. Job P can run, if Job N has not started.
2. Job P can run, if Job N has completed.

In the snapshot below, my job GEMTOPR3 has a negative-dependency on XRPDR3PA.

GEMTOPR3 000 GEMTOPR3 GEMIDB 005 SY2 007743 *NONE* 002 000 1326 10194/2315
--------------------------- SUCCESSOR JOBS ----------------------------
JOB=/XRPDR3PA SCHID=000 (Negative dependency)

Generally, Negative Dependencies are used in the Production Environment, to prevent
contention problems. Say, for example, if two jobs access the same
DB2 Table, it’s a good idea, to have a negative dependency created amongst them.
Q. What are the advanced CA-7 Commands?
You can type CA-7 advanced Forecast commands, to find out the hierarchy of jobs in
the forward order, or reverse-order. FSTRUC Command gives the complete list of
triggered jobs, at all levels, top-to-bottom. FRJOB gives the complete list of
triggered jobs, at all levels in the reverse order, bottom-up fashion. Look, how
I’ve found the complete hierarchy of jobs triggered by my job GEMCAL00.
This is how it works. GEMCAL00 triggers GEMCAPHDR(Header job). GEMCAPHDR on the
other hand triggers GEMCARAL and GEMCAR1L. The AL triggers a complete stream or
wave of my jobs – GEMCARBL, which triggers the *CL, triggering *EL and so on.
Q. What is Job Monitoring? How to check if a job has completed?
When a Mainframe Job completes successfully, it goes to the Log-Area[LRLOG]. The
log-area stores tracking-information – the log of the completed job of the past 5
days. The CA-7 LRLOG Command is used to retrieve from the logs, information about
the previous runs of a job. I have scribbled below, how you can code several
different options on the LRLOG Paragraph.

Log of the job, for the past 5 days.

Log of the job, for the run on 2010-07-19(Julian Date 197 day of the year 2010).

When a job abends at a particular step, you may re-start the job from the next
successive step, you may force-complete the job, or you may cancel the job. Force
completing a job, force-fully marks the job as complete(even if the job has not run
entirely successfully). All triggered down-stream jobs are brought into the CA-7

Cancelling the job off, is like stopping the job altogether. With this the entire
job-cycle downstream will be held up/hung.

This command tells, which jobs abended and were restarted in last 24 hours.

This command tells, which jobs abended and were force-completed in last 24 hours.

This command tells, which jobs abended and were cancelled off in last 24 hours.

This command is used find out information about the Last job-run.