On Spool jobs

On Spool jobs are jobs or started tasks that are submitted externally to Control-M, that is, jobs submitted by TSO users or CICS, or jobs received over an NJE network, and brought under the control of the Control-M monitor using a CMEM rule.

The CMEM rule that causes a job to be an On Spool job (that is, a CMEM rule that brings the external job under the control of the Control-M monitor), must be an ON JOBARRIV rule with a DO FORCEJOB statement.

To inform Control-M that this is an On Spool job and not a regular FORCEJOB request, the job scheduling definition forced by the DO FORCEJOB must "match" the arriving job, as described later in this section.

Control-M controls the entire life cycle of the job, from determining when to execute the job to performing job post-processing, according to the forced job scheduling definition.

Control-M processes On Spool jobs slightly differently than it processes regular jobs. Control-M does not submit the job because the job has already been submitted. Instead, Control-M releases the job (if held) when the runtime scheduling criteria are met. Once the job starts execution (whether the job previously required releasing or not), it is controlled by Control-M in the same way that Control-M controls regular jobs. Control-M waits for the job to finish, reads its SYSOUT, and performs all post-processing actions defined in the job scheduling definition.

Note: For Control-M/Assist users Control-M will not release the job, since the user will most likely will not submit the job in held status from his third-party-vendor scheduling product.

Creating On Spool jobs

The following components are necessary to create On Spool jobs:

• Job on spool

  The job must have the following characteristics:

  • The MSGCLASS SYSOUT of the job:
    • For JES3 users: must be equal to the Control-M SYSOUT held class.
    • For JES2 users: can be any held SYSOUT class.

    This enables Control-M to read the job's SYSOUT and perform post-processing according to the job scheduling definition.

  • To delay the job's execution and permit Control-M to determine when to run it, submit the job with TYPRUN=HOLD.

  Note: Control-M/Assist users may not wish to implement this recommendation.

• CMEM rule definition

  The CMEM rule definition must contain the following:

  • ON JOBARRIV statement. The job name specified in the ON JOBARRIV statement in this rule must match the name of the job to be monitored. It can be a full job name, or it can be a mask if a group of jobs is to be monitored.
  • DO FORCEJOB statement. The first DO FORCEJOB statement in the rule must force a matching job scheduling definition (described below).
• Job scheduling definition

  The job scheduling definition must have the following characteristics:

  • The job scheduling definition must be forced by the first DO FORCEJOB statement in the CMEM rule.
  • The MEMNAME value in the job scheduling definition must match the name of the external job. A mask can be specified in the MEMNAME field if the same job scheduling definition is used for more than one job.
  • Appropriate runtime scheduling criteria for the job may be defined in the job scheduling definition. This enables Control-M to control the execution of the job (that is, when the job must be run).

    Note: Control-M/Assist users may not wish to implement this recommendation.

  • Desired post-processing actions must be defined in the job scheduling definition.

Handling On Spool jobs

On Spool jobs are handled as follows:

• When the job arrival event occurs, Control-M forces the requested table or job.

  If the MEMNAME value in the requested table or job does not match the name of the arriving job, the table or job is forced and processed regularly by Control-M (a job is submitted when its runtime scheduling criteria are met, and so on).

  If the MEMNAME value in the requested table or job matches the name of the arriving job, the job becomes an On Spool job and Control-M performs the following actions:

  • Replaces the MEMNAME mask (if a mask was specified in MEMNAME) with the name of the arriving Job.
  • Assigns the job ID of the job that triggered the event to the forced job.
  • Forces the job, the forced job appears in the Active Environment screen with status WAIT SCHEDULE ON SPOOL.
• Control-M starts processing the forced job when all runtime scheduling criteria defined in the job scheduling definition are satisfied. If there are no runtime scheduling criteria in the job scheduling definition, Control-M starts processing the job immediately.
• Control-M looks for the job in the spool (to release it, if required).

  If the external job is waiting for execution in HELD state (that is, if the job arrives on spool with TYPRUN=HOLD), Control-M releases it for execution. Otherwise, Control-M verifies that the job is still in the spool (waiting for execution, executing or ended) before deciding to perform post-processing.

• Control-M waits for the job to finish execution, reads its SYSOUT, analyzes the execution results and performs all the post-processing actions defined in the job scheduling definition.

Note: Control-M can only handle NJE jobs as On Spool jobs when they originate on the same NJE node as that on which Control-M is running.

On Spool job scheduling definition considerations

• Job forcing considerations

  Only one On Spool job can be created in response to a job arrival event.

  However, in several cases, multiple DO FORCEJOB actions might match the arriving job. Each of these cases and the job forcing logic applied to them (to prevent multiple On Spool processes for the same external job) are described below.

  • The job arrival rule contains multiple DO FORCEJOB requests. (Each might match the arriving job.) In this case, job forcing logic is as follows:

    The On Spool process (the match between the external job name and MEMNAME) is performed for the first DO FORCEJOB in the first matching job arrival rule only:

    • If a match is found, the job is an On Spool job.
    • If a match is not found, the job is not an On Spool job, even if subsequent DO FORCEJOB actions might match.

    In either case, all subsequent DO FORCEJOB statements in the same rule (if they exist) are handled normally (that is, not as forcing On Spool jobs).

  • The DO FORCEJOB forces a table in which more than one MEMNAME matches the arriving job. In this case, job forcing logic is as follows:

    If a table containing more than one job is forced (by the first DO FORCEJOB statement in the rule, as described above), the first matching job causes the job to be an On Spool job. All the other jobs in the table are forced as regular Control-M jobs, even if they match the job name of the external job.

  • Multiple job arrival rules are triggered by the same job arrival event, and each rule contains one or more DO FORCEJOB statements that might match the arriving job. In this case, job forcing logic is as follows:

    Only the DO FORCEJOB statements from the first triggered rule are executed (as described above). DO FORCEJOB from all other triggered job arrival rules are ignored.

Note: If an On Spool job was purged from the spool but still remains in the Active Jobs File, and another job with the same name arrives on spool and is assigned the same job ID, that later job is not forced.

JCL management considerations

When defining JCL, the following issues must be considered:

• Any attempt to rerun the job (that is, 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 the MEMLIB parameter of the job scheduling definition.
• If the job is not submitted with TYPRUN=HOLD, Control-M cannot determine when the job runs, even if runtime scheduling criteria are defined. In this case, the job might start executing before all the runtime scheduling criteria are satisfied. Post-processing, however, is not performed by Control-M until the runtime scheduling criteria are satisfied.
• The JCL of the On Spool job cannot contain AutoEdit statements, and SETVAR statements in the job definition are ignored. This is because the job is not submitted by Control-M.
• Because the job is not submitted by Control-M, the following job scheduling definition parameters are ignored:
  • SCHENV
  • SYSTEM ID
  • NJE NODE
  • NJE enhanced tracking support is inoperative