CA7 COMMANDS

LQ,JOB=*,LIST=RQMT
Lists all jobs with the requirements status.

:XQM 

This command shows the Queue Maintenance

This screen gives the Jobname along with the following requirements;
J- Job requirement
I- Internal Requirement
E- External requirement
U- User Requirement
N- Network Requirement
SHJV – S -Submit time, H-Hold, J- JCL Error, V-Verification.
*RST - Restart job

In XQM,
- x - before the Jobname; opens the job. (If the job doesn’t have *RST)
When the job is opened,
x- in front of the requirement to post off the requirement.
e- Edit the jcl of the job
In the opened jcl, PF, PB (in the line nos.) works as F7, F8.
SR- save replace the jcl.
Exit- exit from editing jcl, to xqm.

f- only in front of the job with *rst.

This will open the restart screen for this job.
Give the reason, – x – resubmit for the production .
– – complete forcefully.

In case of JCL error it wont restart, until you post off the J req.
To post off a requirement, go to the job and put X before the req, press enter.

Never give S in XQM, it will post off the Submit time req.

Whenever 2 jobs are trying to access the data set, it is called Data contention.

:XQM,JOB=Jobname
This would directly open the job in the REQ Q, showing the requirements.
LQ command:
– Will list information on jobs from the REQ, RDY, ACT of CA7.

Like:

Here it shows the

Jobname, Queue name – in which Queue the job is currently,
CA7 ID for the job, or the Job ID
## DeadLine Time- Supposed to begin by this time atlast,
## Submit/Start Time-Expected to start by this time, Due Out Time-supposed to end by this time,
SchID- Schedule ID of the Job
Entry Mode- What is the entry mode of the job in Req q. (SSCN,DEMD,AUTO,RUN,LOAD)
MSTR REQ- Total no. of requirements of the Job.
Job Status- The Status of the Job(Late,Abend- A-SOC7)

LQ,JOB=jobname
– This command shows the current status of the job, whether it is active, in an abend
status, or if it is waiting on some kind of dependency. This command is useful in
showing what queue the job is in. The queues are request, ready or active.
LQ,JOB=DHD8009A – displays:

:LQ,JOB=jobaname,LIST=RQMT
This command displays the job with all the requirements.

:LQ,JOB=AB*,LIST=RQMT.
 Lists all the jobs with names starting with AB, and listing all the requirements.

:LQ,JOB=AB*,ST=LATE
Lists the jobs which have Late Status.

:LQ,JOB=AB*,ST=SKEL
Lists the jobs with Skeleton Status.

:LQ,JOB=*,ST=RSTR similar to :LQ,ST=RSTR

Lists the jobs which are in the Restart or Abend State.
LREQ Command :
This command shows the REQUEST Q.

:LREQ,JOB=JOBNAME 

LREQ,JOB=TAWWTSOL
This Lists the job TAWWTSOL with all the details like jobid, time, schid, entry mode, requirements.

Like in this screen shot, it shows that this job is waiting in the REQ q, with only one requirement of Submit
time. It will run on the time specified here.

:LREQ,JOB=AB* 
This lists the jobs residing in the REQ q with names starting with AB… , with their respective
requirements.
:LREQ,JOB=jobname,LIST=ALL 

This lists all the requirements for this job, like JOB INFO, REQUIREMENT STATUS, JCL INFO.

Contd.:
JCL INFO;
LRDY Command :
Will display jobs that are currently ready to run. Jobs that are in this queue are sometimes
waiting on an initiator or have a JCL error, which need to be requeued by operator to be placed in LIST
queue.
Here we get the Jobname, jobid, deadline time, submit/start time, due-out time, schid of the job and
importantly the STATUS of the job(late).

LRDY,ST=LATE  Similar to LRDY,JOB=*,ST=LATE 

This displays all the jobs with the LATE Status.
LACT command:

LACT
This displays all the jobs present there in the ACTIVE Q.
Here it also gives the JOB STATUS as Condition codes,LATE.

LACT,JOB=Jobname (or) * (or) AB* 

LPRRN Command:

LPRRN 
This displays the job information from the prior run queue. Will give information about the last
successful completion of job.

LPRRN,JOB=Jobname  displays:
LRLOG Command
Displays the log of all the jobs for 3 days or the Last 5 runs history . It displays whether the job was force
completed,canceled, abended or was completed successfully.
In LRLOG, we get the Actual Start and End Time of the JOB.

LRLOG,JOB=*,DATE=* 

LRLOG,JOB=DVC0550A,DATE=* 

Item Description
A. Describes the Type of Event
C- CompletionF- Force Complete
R- Restart X- Cancel

B. Date and time that the event was written to the run log. The date is in
Julian format and the time is in hours and minutes, military time.

C. Describes the type of object that was involved with this event
J- Job E- External Job
I-Input Network O- Output Network

D. The name of the job.

E. The CA-7 assigned job number.

F. The schedule ID.

G. The system name.

H. The status of the job at the time the event occurred.

 COMP- Normal completion
Snnn - Abnormal System Completion (nnn = abend code)
Unnn - Abnormal User Completion (nnn = abend code)
Cnnnn - Job level condition code
JCLER -JCL Error
Cancel - Job canceled
FCOMP- Job Force Completed, REQUE -Job Requeued
FAIL -Special job UCC7Rxx failed

I. The entry mode of the job.

SSCN Schedule scan
AUTO Trigger
DMND DEMAND command
RUN Run command
LOAD LOAD command
PS Personal Scheduling
ARFJ ARF recovery job

J. If job was brought into system through a trigger, or as an ARF

recovery job, then this field will contain the job number that triggered
this job in. Otherwise, it will be zero.

K. Starting date and time.

L. Completion date and time.

M. An L at the end of the completion time indicates that job was late.

N. For Force Completes, Restart, and Cancel events, if a reason was

supplied, then it will display.
LIST COMMAND:

LIST 
Will display a jobs currently in abend queue that are waiting to be restarted.
DEMAND Command:
One of the Entry Mode of a JOB into the Request q.
* Always use DEMDH & SCHID while demanding a job.

DEMAND,JOB=Jobname,SCHID=xx,DATE=xxxxx,TIME=xxxx 
DEMAND,JOB=JobA,SCHID=01,DATE=07277,TIME=1900 
This command will DEMD the jobA with SCHID 01 instantly, which would be in there in the REQ q
with the Requirement of the Submit Time. This JobA will remain in the REQ q and will run at time 1900 on
date 07/277(Julian Date).

Should not Demand any job like this:

DEMAND,JOB=Jobname 
In this case, the job will start running instantly, as there is no requirement of the Submit time.

*~* Alwayz give the DEMAND command with HOLD i.e. DEMANDH. As this would give some time
to recheck the Job, Jobname, schid etc..
Also there is no SCHID in the above command, so it will by default take the first schid defined in the schedule
definition of the JOB

DEMANDH,JOB=Jobname,SCHID=xx 
This is the correct way to demand any job.
After checking the Jobname, schid etc., we can POST OFF the H (Hold) requirement of the Job in the XQM.
Using DEMANDH we can get enough time to crosscheck the details.

DEMANDH,JOB=Jobname,SCHID=xx,SET=NTR 
If we don’t want a job to Trigger any other job, we can demand it using SET=NTR
This SET=NTR sets the job to NO TRIGGER, i.e. this job will run with schid=xx and wont trigger other jobs in
the stream.

jobAjobBjobCjobDjobE.
Want to demand jobC but don’t want D & E to run.

Here we can use Demand Command;

:DEMANDH,JOB=jobC,schid=xx,SET=NTR
Here SET=NTR means No TRiggering
Or we can use
:RUNH,job=JobC,schid=xx, SET=NTR
LIMITATION of DEMD :
We can demand a job which is present in the CA i.e. which is defined in the CA7.(in DB.1, DB.7 …..)
/*/
* We can RUN a job which is NOT DEFINED to ca7 thru CA7 using RUN command.
(Print Screen -6,7,8.)

Goto DB.7
FE- Fetch Edit. (F-fetch only)
Member- …..
DSN-….. JCL ID- …

SAVE it.
Overtype EDIT with RUN or RUNH….
Then
Check it in XQM panel.

/*/

RUN COMMAND:
RUN,JOB=Jobname,S
RUN,JOB=jobA, -This command will run the jobA instantly.

RUN,JOB=Jobname, -This command will run the jobA instantaneously and wont trigger other jobs in
stream.

Set = ntr is default.

CANCEL COMMAND:
/*/ Always Use jobID while CANCELing a JOB. Give Reason.

CANCEL the job:

Always use jobID for cancelling any job, do not use Jobname as it would cancel all the intances of the job. As
there could be multiple instances of the same job in the REQ q.

CANCEL,JOB=jobID, REASON=TXT….

CANCEL,JOB=jobID,REASON=txt,FORCE=YES.

To cancel a job in REQ Q;

(1) go to xqm, give –c- before the Jobname will cancel the job.
(2) :CANCEL,JOB=jobID, REASON=TXT….

To cancel the job in RDY Q,

Cancelling forcefully or directly.

:CANCEL,JOB=jobID,REASON=txt,FORCE=YES.

We can cancel a job RDY Q by;

(1) Requeue the job to the REQ Q, and then Cancel it.
:REQUEUE,JOB=JOBID.
(2) Cancel it directly using the jobID with FORCE=yes.
If 2 option is not working then use 1 option.

CANCEL,JOB=JOBID,REASON=TXT,FORCE=YES
Here we are using force to cancel this job.
LJOB command:
LJOB is used to list the jobs.
LJOB,JOB=Jobname,LIST=ALL

LJOB,JOB=ADBMACCM,LIST=ALL
This displays or lists all the information of the job like Job Information, Schedules, Step and DD information,
requirements and network connections. Means all the information about this job.
LJOB,JOB=JOBNAME,LIST=RQMT

Lists the requirements of this job.

LJOB,JOB=jobname,LIST=TRIG - This command displays the jobs which get triggered on the completion
of this job.
Here job ORCUSTSB triggers the following jobs.
LJOB,JOB=jobname,LIST=RQJOB
This command will tell you what job requirements that need to be satisfied before the job you are
inquiring on can be released to run.

LJOB,JOB=Jobname,LIST=NODD
Displays all the job info excluding the DD info.
LJOB,JOB=jobname,LIST=DEPJ

LJOB,JOB=JobA,LIST=DEPJ -This command will tell you what jobs are dependent on this jobA
running successfully before they can run on CA-7. In this situation JobA would be a requirement on JobZ.

Ex:
LJOB,JOB=DZZ0020A,LIST=DEPJ This command will tell you what jobs are dependent on DZZ0020A
running successfully before they can run on CA-7. In this situation DZZ0020A would be a requirement on
DZZ0050A.
LJOB,JOB=jobname,LIST=STEPDD
Displays job, step, and DD information.

LJOB,JOB=jobname,LIST=RQDSN
– Displays data set requirement information on job.
LJOB,JOB=jobname,LIST=RQUSR 

LJOB,JOB=ACHGACCM,LIST=RQUSR
– Displays user requirements only.
JCL & LJCL command:

JCL,JOBNAME 
Opens the JCL of the job in EDIT mode.

Here to move up, down use PF, PB as shown above. Save replace to save the changes made in the jcl.

LJCL,JOB=jobname 
Opens the JCL of the job in BROWSE mode.
Pressing ENTER shows the next page of jcl.
LDSN command:

LDSN,DSN=DataSetName,LIST=ALL

LDSN,DSN=LALIT.job.test,LIST=ALL
Lists all the information about this DSN (Lalit.job.test) like which jobs are using this DataSet and their
steps(step no.) in which the dataset is being used. Also what is the disposition whether the job is using it as
SHR, OLD(exclusive rights).
LSCHD command:

LSCHD,JOB=Jobname,LIST=CALS
Lists the schedule of the job.
But this lists only for those jobs which have the entry mode of SSCN.

Here this job has total 6 schids, date/time of the last maintenance.
Description of each schid like DOTM, LEADTM, SUBTM, STARTTM. Whether it is scheduled on the daily,
weekly or monthly basis.
Here in this screen, it shows the schedule of job with its schid, whether it is a daily, weekly or a monthly job.

Also shows the Triggered jobs

In the above LSCHD command, LIST=CALS means the scheduling calendar of the year.
FSTRUC Command:
This is used for the ‘Forward Structure of the JobStream’ of the job.

FSTRUC,JOB=Jobname,SCHID=xx

FSTRUC,JOB=ORCUSTSB,SCHID=01
Displays the whole forward job structure of the job stream ORCUSTSB with schid=1.

Here in the 2nd screen,

Level Nos, Jobname, Expected or scheduled Start and End DTTM(Date Time).
Triggering – which of the above jobs have triggered this job.
SID – schid.

We can know the triggering job also by LJOB,JOB=Jobname,LIST=TRIG.

Suppose there are 2 streams of jobs starting with the jobA;
Job stream with schid 02 JobA  JobP  JobQ  JobR

| Job F | Job Z
| |
Jobstream with Schid01 JobA  JobB  JobC  JobD

Here, Job B triggers JobC and JobF.

JobC triggers JobD and JobZ as well.

To see the whole structure of JobA with schid 01 we use FSTRUC.

By the fstruc command we get this info with level nos.
Level no. JobName
--- JobA
1 JobB
2 JobC
02 JobF
03 JobD
03 JobZ
So now its clear that JobB trigs two jobs JobC, JobF so both have the same Level nos.
Also JobD, JobZ are trigg by the same Job so same level nos. for them too.

Now in this scenario, only by this level no., its difficult to understand which job Triggered JobZ.
We can know this using command;
LJOB,JOB=Jobname,LIST=TRIG.
Ljob,job=jobz,list=trig
FRJOB,JOB=Jobname,SCHID=xx 
This command displays the reverse Structure of the Job in the Stream.

Suppose we want to see the reverse forecasting of job ACSFTPCL , from the JobStream of OCRUSTSB shown
above.
FRJOB,JOB=ACSFTPCL,SCHID=01
FORECASTING of the JOB :

FJOB,JOB=*,FROM=(mmddyy,hhmm),TO=(mmddyy,hhmm) 
Here (mmddyy,hhmm) is the date as in months date year – 092207(for Sept. 22, 2007) with Time=
2200.
It lists out all the jobs SSCN and RUN in this particular time period.

FJOB,JOB=*,FROM=(100407,0100),TO=(100507,1400)
It displays;
FJOB,JOB=AB*,FROM=(mmddyy,hhmm),SPAN=24
This gives all the jobs with names starting with AB… which ran in the span of 24 hrs starting form the
Date & Time specified as above.

Here is the ex.;

In this command we are retrieving data of jobs (names starting with AC….), which ran during the span of 10hrs
starting from the time 0100hrs on date Oct. 06, 2007 i.e.(100607).

Here in this screen shot we get the start, end time of the job… with schid.
SCHDMOD COMMAND:

SCHDMOD 
Displays CA7 Modification to resolved schedule dates.

In this panel, for viewing – LIST, updating the changes – UPD.

Give the Function as LIST then JobName, and schid.

This is the listing or display of the Schedule of the job ORCUSTSB.

Here 0 means job is not scheduled or not running on this date/day.
1 – job is scheduled on this date/day.
Encircled nos. is the 5thday, 10th day, 31st day of the month.

For changing the schedule of a job,

Replace 0 by 1 to run a job on the when it is not scheduled.
Replacing 1 by 0 means not scheduling the job to run on that specific day.
Then for Updating this change,
Inplace of LIST write UPD. 
ADDRQ Command:

Adding requirements to a job. Here we always use the JOBID

These req. could be User, job dependency.

ADDRQ,JOB=jobID,DEPJOB=jobname
Like,
ADDRQ,JOB=9825,DEPJOB=DLIB1801
| |Jobname..
| job ID of the job to which we are adding the requirement.

Here we are adding the requirement DEPJOB i.e. Job Dependency to the job with JobID 9825.
We are making the job with ID 9825 dependent on the job DLIB1801. Thus when this job(Jobname) runs then
only the job(jobid) will start.

ADDRQ,JOB=jobID,USR=TxT1
ADDRQ,JOB=jobID,USR=TxT2
ADDRQ,JOB=jobID,USR=TxT3

We are adding the user req. to the job(jobID).

Text msg to be displayed in the job req., thus giving some info. to user while going through the req.
LJOB,JOB=GA08B539,LIST=TRIG

For dataset contention;

To check who has the dataset;
Goto tso; option 6 ;give the following command with the full dataset name( with generation)

WHOHAS DSN 

EX:
WHOHAS P.FP.F101.FPI041.G2469V00

Give so/p as

===> whohas P.FP.F101.FPI041.G2469V00

ZB64-XMXDTSO /S
***
Call operator to cancel the userid.

ENQ SYSDSN dataset name

Ex. ENQ SYSDSN P.FP.F101.FPI041.G2469V00

Demanding a job in abend status:

DEMANDH,JOB=JOBNAME,SET=NTR,TYPE=RES
Dead line Time:
It is the time by which the Job should meet the requirements and should start successfully.

Due Out Time:

It is the time before which the Job should complete successfully.

Elapsed Time:
Average time of last five successful runs of the Job is called Elapsed time and is calculated
by CA7.

Submit Time:It is the time where the Job should get submitted to the Operating System.

Lead Time/ Look Back Time:

It is the time where we can look back for the execution of the Job in the previous run
where we can post the requirements if they are met.
• Lead time varies from 0 to 99.
 • 0 à Indicates no lead time is to be considered when satisfying this job's
requirements.
• 98 à maximum lead time value is 98 hours.
• 99 à Each predecessor job must complete normally while this job is in the request
queue. This is a special case, even though it is equivalent to zero lead time. Because,
the requirement is never to be considered as already satisfied when the job enters
the queues.
Restart :
The term restart is interpreted as restarting the job in the step in which it has failed. We
can even restart from any other step also.

Restarting a Job in CA-7:

Insert the restart card in jcl and resubmit it in xqm panel.

Restarting a Job in CA-11:

In Ca11 the step where the Job has to start is already tracked and we have to restart it
from xqm panel.
But we can even change the step name from where it should be started.

Trigger :
Used to describe relationships between jobs in the same schedule. For example, job1 can
trigger job2. Job2 is then described as having been triggered by Job1.
JOB1JOB2JOB3
In the given example for Job2, Job1 is called the Predecessor Job and Job3 is called as the
Successor Job.

Dependencies:
In the above example Job1 has an internal requirement of JobA and Job1 will get posted
only when JobA runs successfully. Hence Job1 is said to be dependent on JobA.

In the given example for Job2, Job1 is called the Predecessor Job and Job3 is called as the
Successor Job.
JOB1JOB2JOB3
In the given example for Job2, Job1 is called the Predecessor Job and Job3 is called as the
Successor Job.
Common CA-7 Terms and Definitions

 
When a job enters into the CA-7 queue it can complete normally, execute and fail, or wait
in the queue until all requirements are satisfied. For jobs that execute and fail the
operator can take these actions –

 
FORCE COMPLETE - A failed job is marked within CA-7 as a normal completion. Jobs
waiting for the successful completion of this job will now run - if all other requirements of
the job are satisfied.

 
CANCEL - A failed job is removed from the CA-7 queue. Jobs waiting for the successful
completion of this job will not run unless the requirement for the failed job is manually
satisfied and if all other requirements of the job are satisfied.

RESTART - The term restart is interpreted as restarting the job in the step in which it
has failed. (Or) Restart the failed job from the particular step as per job document ( Prose
which defined for that job .
 
RE-RUN - The term re-run is interpreted as re-running the job from the top, or first step
of the job. RESUBMIT and RE-RUN have the same meaning.
 
Other common terms include -
 SCHID - A schedule or job stream can have many different variations. Each variation is
called a schid or schedule id. For example, Job1 may trigger Job 2 on schid 1, but on
schid 3 Job 1 may trigger Job 3.

HOLD - A job can be placed on hold before or after it enters the CA-7 queue. The job
will remain in hold, meaning it will not run, until the hold is removed.

OVERRIDE - Sometimes it is necessary to modify the regular JCL (referred to a the

MASTER JCL). In such cases the term used is OVERRIDE. This process can be done
prior to a job executing or after a job has failed, and recovery requires modification to the
JCL.