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.5 Multiple CPU Considerations<br />

If you knew the outage was going to be short, you could<br />

MOVEOVER specific schedules by issuing this command <strong>for</strong><br />

each schedule you want moved over. The TARGET field is<br />

optional and defaults to the CPU on which the MOVEOVER<br />

command is being issued. It gives you the flexibility to issue<br />

the command and cause it to be executed on another CPU.<br />

At some point, the original Master CPU is available. It must<br />

be given back control of <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong>. Thus, you<br />

use the operator command (from SYSID 1):<br />

SC MOVEOVER RESTORE=Y<br />

which will cause all schedules (even those currently executing)<br />

that were controlled originally by the CPU that was down, to<br />

be moved back.<br />

Centralized<br />

In a centralized environment, there are no schedules that have<br />

a user-specified SYSID from which they are controlled. This<br />

means that you have never filled in the RUN ON SYSID field<br />

when using the Schedule Definition panel. Consequently, all<br />

jobs will be controlled on the first SYSID in the list of SYSIDs<br />

defined in the <strong>CA</strong>IJGEN macro which is the the Master CPU.<br />

All other CPUs in the list are Slave CPUs.<br />

The simplest case is that if a Slave CPU is down, nothing has<br />

to be done with <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong> as POWER will have<br />

been changed in a manner to handle this situation.<br />

Now consider what must be done if the Master CPU goes<br />

down. One of the Slave CPUs must be made the Master so<br />

that <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong> can continue controlling the<br />

schedules and jobs. The workload from the Master CPU must<br />

be moved over to the Slave CPU and the Slave CPU made to<br />

simulate the Master CPU. You may do this by executing a<br />

batch program, <strong>CA</strong>JMMOV0, but first you must use the<br />

SHUTDOWN operator command to shutdown <strong>Unicenter</strong><br />

<strong>CA</strong>-<strong>Scheduler</strong>, then run the following job on the slave CPU.<br />

// JOB <strong>CA</strong>JMMOV<br />

// EXEC <strong>CA</strong>JMMOV<br />

/<br />

/&<br />

After the job completes, bring up <strong>Unicenter</strong> <strong>CA</strong>-<strong>Scheduler</strong> on<br />

that CPU again. It will now per<strong>for</strong>m as the Master CPU.<br />

Executing the <strong>CA</strong>JMMOV0 program on a CPU has a "permanent" effect, in that<br />

the CPU will become the Master (control all schedules and jobs, and per<strong>for</strong>m<br />

AUTOS<strong>CA</strong>N) until the program is executed on a different CPU. If <strong>for</strong> any<br />

reason a <strong>for</strong>mat of the tracking file becomes necessary, you must run<br />

7-24 <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!