Unicenter CA-Scheduler Job Management for VSE User Guide
Unicenter CA-Scheduler Job Management for VSE User Guide
Unicenter CA-Scheduler Job Management for VSE User Guide
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
6.1 Commonly Asked Questions<br />
If the job or schedule is already on the tracking file (it would<br />
be in a completed or canceled status), the older one is purged<br />
from the tracking file. If the job is on the tracking file and not<br />
completed or canceled, then the RUN command is in error.<br />
With the RUN command, you can place the schedule or job in<br />
a HELD status. This will give you a chance to take any other<br />
manual actions you deem appropriate. Further, when you use<br />
the RUN command to pull in a schedule, you can give it a<br />
date so that only applicable jobs in the schedule are selected.<br />
ADD<br />
Causes a job to be added to the tracking file. The job does not<br />
have to be on the database. If it is on the database, you would<br />
use this command instead of the RUN command if you<br />
wanted to change any keyword values. Normally, you only<br />
use ADD <strong>for</strong> one-time jobs.<br />
You do not have to specify a schedule name. If you do, it will<br />
be added to that schedule. If you do not specify a schedule<br />
name, it will use a schedule name of $DYNx, where x is the<br />
POWER SYSID of the system from which the command was<br />
issued.<br />
REQUEST and SREQ<br />
Cause a REQUESTED schedule or job to be activated which<br />
means it is moved from the inactive queue to the active<br />
queue. Once in the active queue, it is handled normally.<br />
The way that a schedule or job is made 'on-request' is by<br />
giving it a selection criteria of REQUESTED. A REQUESTED<br />
criteria causes the schedule or job to be selected every day<br />
and placed on the tracking file.<br />
The difference between REQUEST and SREQ is that, with<br />
REQUEST, the REQUESTED schedule or job is moved to the<br />
active queue along with all its successors. The SREQ<br />
command handles successors differently: SREQ will not<br />
activate a successor if it involves other requested jobs. A<br />
successor of an SREQed schedule or job will not be moved to<br />
the active queue if:<br />
The successor's criteria statement contains the keyword<br />
REQUESTED or<br />
That successor is also the successor of some other<br />
requested job in the inactive queue<br />
There is a separate subtopic devoted to requested jobs in the<br />
next chapter. If you plan to use this facility, you should<br />
review the subtopic on REQUESTED work.<br />
Chapter 6. Tips 6-17
Change language