03.03.2015 Views

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

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

7.1 On-Request Schedules and <strong>Job</strong>s<br />

7.1 On-Request Schedules and <strong>Job</strong>s<br />

7.1.1 Discussion<br />

This topic discusses on-request schedules and jobs and gives you many<br />

examples of criteria language.<br />

On-request schedules and jobs are ones that are selected every day, and placed<br />

in an inactive queue, in case they are needed. They remain in an INACTIVE<br />

status until they are activated by an operator command which means that you<br />

cannot determine in advance whether the schedule or job will be needed on<br />

any particular day.<br />

You define an on-request schedule or job using REQUESTED, a Gregorian<br />

calendar reserved word, in its selection criteria.<br />

When the autoscan process runs, all REQUESTED schedules and jobs are<br />

selected along with their successors and placed in <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong>'s<br />

tracking file in an inactive queue. The only way they can be removed from the<br />

inactive queue is using the operator command REQUEST or SREQ. When<br />

removed from the inactive queue, they are placed in the active queue and will<br />

then be handled as normally selected jobs.<br />

An important difference between the REQUEST and SREQ commands is that<br />

REQUEST also places the successor schedules and jobs in the active queue.<br />

The SREQ command handles successors differently: SREQ will not activate a<br />

successor if it involves other requested jobs. A successor of an SREQed<br />

schedule or job will not be moved to the active queue if:<br />

■<br />

■<br />

The successor's criteria statement contains the keyword REQUESTED or<br />

That successor is also the successor of some other requested job in the<br />

inactive queue<br />

All schedules and jobs that have not been requested by the next autoscan are<br />

purged from <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong>'s tracking file, regardless of which<br />

BACKLOG values they had defined.<br />

There is a guideline you should follow when using the REQUESTED keyword:<br />

To ensure that simulation produces reason codes that match those produced<br />

by <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong>, specify REQUESTED after job and schedule names<br />

in selection criteria whenever possible.<br />

7-2 <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong> <strong>User</strong> <strong>Guide</strong>

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!