Handling component shutdown needs

The Ex-ComponentStopping Sub Application contains jobs that are used to shut down (stop) Control-M components. Normally, shut down of components is not required. However, situations can arise thuire component shutdown. These situations can range from extreme emergencies (as handled in this sample draft) to minor malfunctions, repairs, or maintenance.

Each job in this Sub Application shuts down a single component. With the exception of the job that shuts down the gateway, which must run last, the jobs in this Sub Application can run in any order or sequence.

Defining jobs that stop the GCS, and GUI servers and CMS and BIM

These following jobs should run only after ShutDownAllSystems (in the Ex-EmergencyProcs Sub Application) has ended successfully:

• BIMStopped: Stops the Batch Impact Manager Server
• CMSStopped: Stops the Configuration Management Server
• GCSStopped: Stops the Global Conditions Server
• GUIServerStopped: Stops the GUI Server

Defining jobs that implement operating system commands, and other general information about the jobs

The jobs contain the following:

• Each of these jobs issues an operating system shutdown command. For each of these jobs, in the General tab, the Command field contains the following operating system Stop command to be executed:

  ctl -u emuser -p empass -C component -all -cmd stop

  where component is the relevant Control-M component (GAS, GCS, etc).

• To ensure that these jobs will not run until their predecessor job has ended, In the Prerequisite tab, each of these jobs has ShutDownAllSystems-ENDED defined as an In Condition. (This condition is only added after ShutDownAllSystems has ended successfully.) The In Condition is assigned an Order Date.Ensuring that successor jobs can run
• After each of these jobs ends successfully, it adds two Out Conditions (for example, EX_GCSStopped and EX_GCSStopped-ENDED), either of which can be used by successor jobs. The date definition for these conditions is Order Date, which ensures that the condition is added to the system with the original scheduling date of the job. (The successor job, GatewayStopped, uses the name-ENDED condition.)

Defining a job that stops the gateway

The GatewayStopped job stops the Gateway. It should only be run after the other components have been stopped. Like its predecessor jobs, this job issues an operating system Stop command.

The job contains the following:

• In the General tab, the Command field contains the following operating system Stop command to be executed:

  ctl -u emuser -p empass -C Gateway -all -cmd stop.

• To ensure that the job runs only after all its predecessor jobs have ended successfully, GatewayStopped contains the following definitions:
  • In the Prerequisite tab, the In Conditions that match the Out Conditions (the name-ENDED condition) are defined in the Conditions section of each of its predecessor jobs. These In conditions are assigned an Order Date. The Conditions Relationship defines an AND relationship between the In Conditions.
• To ensure that successor jobs can run, after GatewayStopped ends successfully, it adds the Out Condition EX_GatewayStopped (with an Order Date that can be used as an In Condition by other jobs.