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

supportcontent.ca.com
from supportcontent.ca.com More from this publisher
03.03.2015 Views

6.2 Pitfalls 6.2 Pitfalls This topic discusses some of the pitfalls you may encounter. 6.2.1 Using Operator Commands on the Status Display Panel You are able to issue operator commands from a status display by just keying in the command (first four characters) to the left of the schedule or job. You can even issue more than one command at a time. Pitfall: When keying in a command to the left of a schedule or job in the Online Status Display, be sure you are on the correct line. It is easy to cancel the wrong job. While on the subject of operator commands in status displays, here is a clarification, not a pitfall. Remember, when using the commands in this manner, that they are processed sequentially and stop being processed upon encountering an error. For example, there is no reason to cancel a schedule and then the jobs in that schedule. 6.2.2 Cancelling and Purging a Job Suppose you have a schedule that consists of four jobs: JOB1 through JOB4. JOB2 requires JOB1; JOB3 requires JOB2; and so on. If you CANCEL JOB3, whether you also PURGE it, JOB4 will always wait for JOB3. You can manually override this with a POST or FORCE command. Suppose that JOB3A has JOB3 as a predecessor. If JOB3 is canceled and not purged, the predecessor JOB3 is ignored when you issue a RUN JOB3A command because JOB3 has been canceled but is still on the tracking file. If you purge JOB3 before issuing the RUN JOB3A command, JOB3A waits for JOB3 to complete. You have to RUN JOB3 to put JOB3 back on the tracking file. Do not use the PURGE command unless you plan to put the job back on the tracking file by issuing a RUN command. Pitfall: Predecessors for jobs added to this day's production using the RUN command are ignored if they have been canceled by the CANCEL command but not deleted from the tracking file by the PURGE command. 6.2.3 Changing Criteria on Selected Jobs When a schedule or job has been selected, Unicenter CA-Scheduler reviews its predecessor criteria as it exists on the database. What this means is that if you have a schedule of four jobs: JOB1, JOB2, JOB3, and JOB5, where JOB2 requires JOB1, JOB3 requires JOB2, and JOB5 requires JOB3. The schedule has been selected and is on the tracking file. You then add JOB4 and change the 6-20 Unicenter CA-Scheduler User Guide

6.2 Pitfalls predecessor criteria of JOB5 to now also require JOB4. If JOB5 had not yet started, when it is evaluated to start, it will require JOB4, but JOB4 was never selected. Therefore, JOB5 will never be submitted. It will always be awaiting JOB4. If this happens, we recommend that you CANCEL and PURGE JOB4 and then issue an ADD command for JOB4. Pitfall: When changing predecessor criteria on the database for jobs that are selected and are already on the tracking file, be aware that the jobs on the tracking file will be evaluated based on the most current data on the database. Do not change the criteria of active jobs. 6.2.4 Backlogging Over Two Autoscans The subject of backlog is covered in the topic Backlogged Work in the chapter "Techniques." When a schedule gets backlogged (autoscan occurred before the schedule completed) due to the first autoscan occurring, it is handled as you would expect. If, however, it does not finish before the next autoscan (meaning it has been in the system for 48 hours), when it does finish, the new schedule that is loaded is evaluated for the autoscan day on which it is loaded which means that if a schedule that is selected on both Monday and Tuesday and has its Monday's version backlogged until Wednesday; Tuesday's version will never be run. That is because the evaluation takes place when Monday's schedule completes, which is Wednesday, but it does not run on Wednesday. Always watch backlogged work carefully. Pitfall: Backlogged work that goes beyond a 48-hour period can be lost if not monitored carefully. 6.2.5 Resetting Global Parameters Global parameters are initialized only when the tracking file is initialized. They are not reset at autoscan time. Once a value of a global parameter is set, it is only reset when someone actually changes its value to something else. That is, predecessor evaluation of schedules and jobs takes place based upon the current value of the global parameter regardless of when that value is set. If the preceding is not the way in which you desire to operate, you could have a batch job that is submitted at a specific time (say immediately following autoscan) that executes the Unicenter CA-Scheduler program CAJUCMD0 and supplies transactions that set the global variables to the values you want. Therefore, the pitfall: Pitfall: A global parameter only gets set. If you want it reset, you must set it to another value. There is no such thing as resetting a global parameter. Once a global parameter is set to a specific value, all unsatisfied predecessors are reevaluated. If any schedules or jobs are waiting for that global parameter to take on that value, those global predecessors are marked as satisfied. Chapter 6. Tips 6-21

6.2 Pitfalls<br />

predecessor criteria of JOB5 to now also require JOB4. If JOB5 had not yet<br />

started, when it is evaluated to start, it will require JOB4, but JOB4 was never<br />

selected. There<strong>for</strong>e, JOB5 will never be submitted. It will always be awaiting<br />

JOB4. If this happens, we recommend that you <strong>CA</strong>NCEL and PURGE JOB4<br />

and then issue an ADD command <strong>for</strong> JOB4.<br />

Pitfall:<br />

When changing predecessor criteria on the database <strong>for</strong> jobs<br />

that are selected and are already on the tracking file, be aware<br />

that the jobs on the tracking file will be evaluated based on<br />

the most current data on the database. Do not change the<br />

criteria of active jobs.<br />

6.2.4 Backlogging Over Two Autoscans<br />

The subject of backlog is covered in the topic Backlogged Work in the chapter<br />

"Techniques." When a schedule gets backlogged (autoscan occurred be<strong>for</strong>e the<br />

schedule completed) due to the first autoscan occurring, it is handled as you<br />

would expect. If, however, it does not finish be<strong>for</strong>e the next autoscan (meaning<br />

it has been in the system <strong>for</strong> 48 hours), when it does finish, the new schedule<br />

that is loaded is evaluated <strong>for</strong> the autoscan day on which it is loaded which<br />

means that if a schedule that is selected on both Monday and Tuesday and has<br />

its Monday's version backlogged until Wednesday; Tuesday's version will<br />

never be run. That is because the evaluation takes place when Monday's<br />

schedule completes, which is Wednesday, but it does not run on Wednesday.<br />

Always watch backlogged work carefully.<br />

Pitfall:<br />

Backlogged work that goes beyond a 48-hour period can be<br />

lost if not monitored carefully.<br />

6.2.5 Resetting Global Parameters<br />

Global parameters are initialized only when the tracking file is initialized. They<br />

are not reset at autoscan time. Once a value of a global parameter is set, it is<br />

only reset when someone actually changes its value to something else. That is,<br />

predecessor evaluation of schedules and jobs takes place based upon the<br />

current value of the global parameter regardless of when that value is set.<br />

If the preceding is not the way in which you desire to operate, you could have<br />

a batch job that is submitted at a specific time (say immediately following<br />

autoscan) that executes the <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong> program <strong>CA</strong>JUCMD0 and<br />

supplies transactions that set the global variables to the values you want.<br />

There<strong>for</strong>e, the pitfall:<br />

Pitfall:<br />

A global parameter only gets set. If you want it reset, you<br />

must set it to another value. There is no such thing as<br />

resetting a global parameter.<br />

Once a global parameter is set to a specific value, all unsatisfied predecessors<br />

are reevaluated. If any schedules or jobs are waiting <strong>for</strong> that global parameter<br />

to take on that value, those global predecessors are marked as satisfied.<br />

Chapter 6. Tips 6-21

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

Saved successfully!

Ooh no, something went wrong!