General Information

Control-O AutoEdit variables embedded in the TABLE, JOB, DATE, and LIBRARY subparameters are automatically resolved (replaced) at time of rule activation. For more information about the AutoEdit Facility, see Chapter 4, "AutoEdit Facility."

DO FORCEJOB schedules a job under Control-M even if the date is not specified as a scheduling date in the Basic Scheduling parameters of the job. It is similar to the FORCE option in the Control-M Table List screen.

When forcing all jobs in a table, the UFLOW subparameter enables you to determine whether the jobs are run as a unique flow.

If the Control-M monitor is active, the DO FORCEJOB statement is executed by the Control-M monitor.

If the Control-M monitor is not active, the DO FORCEJOB statement is queued and is performed when the Control-M monitor becomes active.

If Control-M is not installed, ordering a rule containing a DO FORCEJOB statement fails with an error message.

DO FORCEJOB can also function similarly to the Control-M CMEM facility. The purpose of the CMEM option in Control-M is to permit Control-M to control jobs that are not submitted by Control-M, or to order new Control-M tables, based on the appearance of a job on spool. The Control-O DO FORCEJOB statement permits ordering of such jobs into Control-M based on the appearance of a message.

Control-O handles DO FORCEJOB statements differently for JOBARRIVAL events and messages, JOBEND events and messages, and all other messages. The differences in handling are explained below. For more information, see the discussion of ON SPOOL jobs in the CMEM chapter of the Control-M for z/OS User Guide.

A DO FORCEJOB statement can be distributed to Control-O on a remote system that is identified through the %%$COMMSYS reserved user-defined variable in a preceding DO SET statement. For more information, see the description of %%$COMMSYS in Reserved User-Defined Variables, and Performing an Action on Another System ctoug3

The DATE field

When either ?, DATE?, or ODAT? are used in the DATE field to check the status of the job, the values returned can be accessed by using the following variables:

• %%$CTMJGROUP
• %%$CTMJHLDSTAT
• %%$CTMJJOBID
• %%$CTMJJOBNAME
• %%$CTMJLIBRARY
• %%$CTMJMEMNAME
• %%$CTMJODATE
• %%$CTMJORDERID
• %%$CTMJOWNER
• %%$CTMJRBA
• %%$CTMJSTATUS
• %%$CTMJTABLE
• %%$CTMJTYPE
• %%$CTMLINE#
• %%$CTMLINES
• %%$CTMRC

For more information on these variables, see AutoEdit Facility.

Note: When ? is used in the DATE field, the rule uses an internal DO WAIT TIMEOUT 0 statement in order to force the rule to be processed under the Control-O monitor. The Control-O monitor is where all the relevant data required by the Control-M interface is accessible.

JOBEND Rules or $HASP395/IEF404I Messages

DO FORCEJOB actions specified in a JOBEND Event rule or in a Message rule triggered by $HASP395 (under JES2) or IEF404I (under JES3) are executed only if the terminating job is not under Control-M control. The JOBEND Event rule in this case will not cause a job to be put in WAIT SCHEDULE ON SPOOL state.

JOBARRIVAL Rules or $HASP100 or IAT6101 Messages

$HASP100 or IAT6101 messages indicate the appearance of a job on spool. The process for these messages is the same as the process for Control-M CMEM JOBARRIVAL event. When $HASP100 or IAT6101 is indicated in the ON MESSAGE statement in a rule definition, Control-O intercepts such messages as follows:

1. If the message was issued for a job submitted by Control-M, the DO FORCEJOB is ignored.
2. If the message was not issued for a job submitted by Control-M, Control-M orders the requested table or job. Control-M scans the ordered jobs looking for the job with a MEMNAME that matches the name of the job that triggered the ordering (the job name in the scheduling table can be a job name mask). If one is found, it will appear on the Status screen in WAIT SCHEDULE ON SPOOL state, and is assigned the job ID of the job that triggered the message. If a matching job name is not found, or if more than one job was ordered, the remaining jobs will appear in WAIT SCHEDULE state and Control-M will process these jobs normally.
3. When all Runtime Scheduling criteria of the On Spool job are met, the job is released for execution (from JES held status) by an operator command issued from Control-M. If the job is already running, Control-M will start tracking it. Control-M then controls the job as any other job. It reads the SYSOUT of the job when the job terminates, and analyzes execution results, adds and deletes conditions, performs SHOUTs, and so on. However, there are certain restrictions: Any attempt to rerun the job, either as a cyclic job, by a DO RERUN statement, or by a manual rerun request might fail if the JCL of the job is not found in the library specified in its MEMLIB parameter of the job order.

Other Messages and Events

Messages other than those produced by JOBEND and JOBARRIVAL rules are handled by Control-O as follows:

• If the message was issued by a job submitted by Control-M, or no job ID and job name appear in the message, the job (or table) is handled as usual, meaning, it is ordered and placed on the Active Jobs file.
• If the message was not issued by a job submitted by Control-M, and the message contains a job ID and job name, the job or table is handled similarly to non-Control-M jobs for $HASP100 messages (paragraph #2 above).
• For DSNEVENT or STEP events, the job or table is handled as usual, that is, it is ordered and placed on the Active Jobs file.