Sample implementation tasks

This chapter includes the following topics:

• Overview

• Monitoring mainframe jobs from Control-M/EM

  • Monitoring specific job - PRDDBUP

  • Monitoring all production jobs (PRD*)

  • Using generic and specific definitions

• Creating dependencies between cross-platform jobs

  • z/OS jobs trigger cross-platform jobs, managed by Control-M/EM

  • Cross-platform jobs, managed by Control-M/EM, trigger z/OS jobs

Overview

This chapter describes the implementation of common sample tasks using Control-M/Assist.

After installing Control-M/Assist, follow the steps described in this chapter to implement it. The sample jobs, scheduling definitions and CMEM rule definitions exist in the Control-M sample library, delivered on the installation tape.

Monitoring mainframe jobs from Control-M/EM

Control-M/EM provides centralized control of the job scheduling environment for the entire enterprise. Control-M/EM advanced graphical user interface provides enhanced perception of production flows throughout the entire active environment.

Control-M/EM works in conjunction with Control-M, Control-M/Restart and the Control-M/Assist solution to allow viewing and monitoring, from the centralized Control-M/EM GUI interface, of your mainframe jobs which were scheduled and submitted by any scheduler or user (Control-M, CA-7, OPC, manual submission, and so on). The Control-M/EM GUI thereby becomes the centralized mechanism from which to view and track the entire scheduling environment across all platforms.

Monitoring specific job - PRDDBUP

Task Description

The user wishes to monitor the status of all his production jobs (PRD*), running in the z/OS environment and managed by CA-7, from Control-M/EM. All production job names start with the prefix PRD.

Step 1 – Creating generic CMEM rules - PRD*

In the previously defined CMEM rules table PRDRULES, create a new generic rule to capture job arrival events for jobs whose name prefix is PRD. Using the insert command (I) in the CMEM rule list screen, we create the new PRD* rule.

The PRD* CMEM rule definition is shown below. This rule is activated for an ON JOBARRIV event of jobs whose names are prefixed by PRD. When this event is triggered, the FORCEJOB request forces the job definition into the Active Jobs File. In this FORCEJOB action we use a special CMEM AUTOEDIT variable, %%$JNAME, which will be replaced by the actual job name of the job that triggers this rule.

If, for example, a job whose name is PRDDB2 is submitted, this rule will be triggered and will force job definition PRDDB2 from table PRDTABLE in library CTMP.V600.SCHEDULE.

Using this rule definition we can now capture job arrival events and force jobs definitions generically, without having to define a rule for each specific job.

After completing the definition, the PRDRULES rule table should be reordered, to cause the new rule definition PRD* to be loaded (as described in "Step 3 – Activating definitions and tracking job PRDDBUP").

Step 2 – Creating table and generic JOB definitions - PRD*

In the previously defined table PRDTABLE, define a generic job definition (PRD*) that matches all jobs which can trigger the PRD* CMEM rule. This definition should be the last definition in the table (after the scheduling definition of job PRDDBUP). Using the insert command (I) in the Job Definition list screen, we create the new PRD* definition.

This generic job definition is a template definition. During the processing of a FORCEJOB request of an on spool job, the first definition in the table (PRDTABLE) that matches the job name is forced. Any jobs that don't match a previous specific job definition will always match the last generic job definition PRD*.

The MEMNAME (PRD*) is then replaced automatically by the on spool job name, and the job is placed on the Active Jobs File.

Monitoring all production jobs (PRD*)

Task Description

The user wishes to monitor the status of all his production jobs (PRD*), running in the z/OS environment and managed by CA-7, from Control-M/EM. All production job names start with the prefix PRD.

Step 1 – Creating generic CMEM rules - PRD*

In the previously defined CMEM rules table PRDRULES, create a new generic rule to capture job arrival events for jobs whose name prefix is PRD. Using the insert command (I) in the CMEM rule list screen, we create the new PRD* rule.

The PRD* CMEM rule definition is shown below. This rule is activated for an ON JOBARRIV event of jobs whose names are prefixed by PRD. When this event is triggered, the FORCEJOB request forces the job definition into the Active Jobs File. In this FORCEJOB action we use a special CMEM AUTOEDIT variable, %%$JNAME, which will be replaced by the actual job name of the job that triggers this rule.

If, for example, a job whose name is PRDDB2 is submitted, this rule will be triggered and will force job definition PRDDB2 from table PRDTABLE in library CTMP.V600.SCHEDULE.

Using this rule definition we can now capture job arrival events and force jobs definitions generically, without having to define a rule for each specific job.

After completing the definition, the PRDRULES rule table should be reordered, to cause the new rule definition PRD* to be loaded (as described in "Step 3 – Activating definitions and tracking job PRDDBUP").

Step 2 – Creating table and generic JOB definitions - PRD*

In the previously defined table PRDTABLE, define a generic job definition (PRD*) that matches all jobs which can trigger the PRD* CMEM rule. This definition should be the last definition in the table (after the scheduling definition of job PRDDBUP). Using the insert command (I) in the Job Definition list screen, we create the new PRD* definition.

This generic job definition is a template definition. During the processing of a FORCEJOB request of an on spool job, the first definition in the table (PRDTABLE) that matches the job name is forced. Any jobs that don't match a previous specific job definition will always match the last generic job definition PRD*.

The MEMNAME (PRD*) is then replaced automatically by the on spool job name, and the job is placed on the Active Jobs File.

Monitoring all production jobs (PRD*)

Task Description

The user wishes to monitor the status of all his production jobs (PRD*), running in the z/OS environment and managed by CA-7, from Control-M/EM. All production job names start with the prefix PRD.

Step 1 – Creating generic CMEM rules - PRD*

In the previously defined CMEM rules table PRDRULES, create a new generic rule to capture job arrival events for jobs whose name prefix is PRD. Using the insert command (I) in the CMEM rule list screen, we create the new PRD* rule.

The PRD* CMEM rule definition is shown below. This rule is activated for an ON JOBARRIV event of jobs whose names are prefixed by PRD. When this event is triggered, the FORCEJOB request forces the job definition into the Active Jobs File. In this FORCEJOB action we use a special CMEM AUTOEDIT variable, %%$JNAME, which will be replaced by the actual job name of the job that triggers this rule.

If, for example, a job whose name is PRDDB2 is submitted, this rule will be triggered and will force job definition PRDDB2 from table PRDTABLE in library CTMP.V600.SCHEDULE.

Using this rule definition we can now capture job arrival events and force jobs definitions generically, without having to define a rule for each specific job.

After completing the definition, the PRDRULES rule table should be reordered, to cause the new rule definition PRD* to be loaded (as described in "Step 3 – Activating definitions and tracking job PRDDBUP").

Step 2 – Creating table and generic JOB definitions - PRD*

In the previously defined table PRDTABLE, define a generic job definition (PRD*) that matches all jobs which can trigger the PRD* CMEM rule. This definition should be the last definition in the table (after the scheduling definition of job PRDDBUP). Using the insert command (I) in the Job Definition list screen, we create the new PRD* definition.

This generic job definition is a template definition. During the processing of a FORCEJOB request of an on spool job, the first definition in the table (PRDTABLE) that matches the job name is forced. Any jobs that don't match a previous specific job definition will always match the last generic job definition PRD*.

The MEMNAME (PRD*) is then replaced automatically by the on spool job name, and the job is placed on the Active Jobs File.

Using generic and specific definitions

BMC recommends that generic job definitions (and corresponding generic CMEM rules to force these jobs definitions) be created with all the common processing logic for all jobs which must be monitored from Control-M/EM. Whenever unique definitions for specific jobs or groups of jobs which require different processing logic are needed, they should be created physically above the generic definition.

For example, suppose all production jobs (PRD*) must shout an error message to Control-M/EM alerts monitor when they end NOTOK, but different processing logic is needed for the following jobs:

• Job PRDCICS - sends a job failure e-mail message to [email protected], and the shout message should be sent not only to the Control-M/EM alerts window but also to the z/OS operator console as an unrollable message.

• Job PRDBCKUP - must be automatically rerun (a maximum of 3 times) in case the job ends NOTOK.

• Job PRDDB2 - Should be considered to end OK even if any of its steps abends with user abend U0666. No shout messages are needed in case the job fails.

The following definitions are required:

• A generic CMEM rule to capture all production jobs.

• Table PRODJOBS, to include all jobs definitions

One generic job definition - PRD* to describe the default processing logic of on spool jobs, and three more job definitions for the jobs that required special processing logic.

The following are the 4 jobs definitions:

• PRD* – job scheduling definition

• The generic definition contains a MEMNAME PRD*, and is placed as the last definition in the table.

• When ended NOTOK, the shout message is routed to U-ECS, i.e., the Control-M/EM Alerts Window and the Control-M log.

• The shout message contains the special AUTOEDIT variable %%JOBNAME, which is replaced with the full job name before the shout is executed.

• PRDCICS - job scheduling definition

• PRDBCKUP - job scheduling definition

• PRDDB2 - job scheduling definition

• If any of the job steps (ANYSTEP) complete with user ABEND code U0666, consider the job as ended OK (DO OK).

Creating dependencies between cross-platform jobs

In a multi-platform Control-M environment define global conditions, which are special prerequisite conditions, can be used to create job dependencies between jobs residing in different Control-M installations. For example, you can specify that jobs in Control-M installations on UNIX or Microsoft Windows machines begin executing only after the successful completion of a job that was scheduled and submitted on the z/OS environment.

The standard handling of global conditions is similar to that of non-global prerequisite conditions, that is, view, create, and delete global conditions using the Prerequisite Conditions window. In addition, when Control-M/EM detects the creation or deletion of a global condition in one Control-M or Control-M/Assist installation, it automatically creates or deletes the same global condition in the other Control-M installations, as required.

Global conditions are defined via prefixes specified in the Control-M/EM Global Conditions window. A prerequisite condition is recognized as a global condition when its name starts with a prefix listed in this window and its Control-M installation is defined for that prefix. The following 2 examples demonstrate how to create dependencies between multi-platform jobs. All job definitions, unlike previous samples, will be defined and maintained using the Control-M/EM Graphical User Interface (GUI), and not via the Control-M for z/OS Job Definition facility.

z/OS jobs trigger cross-platform jobs, managed by Control-M/EM

Task Description

All production jobs (PRD*) must set a global OUT condition indicating they ended OK. This allows the creation of dependency relationships between z/OS jobs and other cross platform jobs managed by Control-M/EM. The example below illustrates how to create a dependency between a z/OS job called PRDOS390 and a UNIX job called PRDUNIX. PRDUNIX should be submitted only after successful execution of PRDOS390.

Step 1 – Defining Global Condition prefixes

We use the prefix PRD for all global conditions that originate from z/OS jobs and are targeted to all other Control-M installations across other platforms.

We open the Global Conditions window by choosing Resources => Global Conditions

Figure 4 Global Conditions Window

After clicking the New button. The Global Conditions Details window opens.

Figure 5 Global Conditions Details window

We specify the prefix for the new global condition - PRD.

In the 'From' area, select the Control-M installation on the z/OS environment. Conditions starting with this prefix on the Control-M z/OS platform will thus be recognized as global conditions.

In the 'To' area, select all other Control-M installations where the conditions are to be automatically added/deleted when the same condition is added/deleted in the Control-M for z/OS environment.

Click OK to complete the window.

Step 2 – Creating z/OS CMEM rule and job definitions

We use the previously prepared CMEM rule definition - PRD*, to capture all job arrival events and to force their job definition to the active job file.

Using the previously prepared general job definition - PRD*, add an OUT condition %%JOBNAME-ENDED-OK to the IOA Conditions file. The OUT condition contains AutoEdit variable %%JOBNAME which will be replaced by the job name of the job that triggered this event. Because the job names all begin with prefix PRD, the conditions also begin with the prefix PRD, and thus will be considered as global conditions and be added to the defined target Control-M installation.

Additional methods of adding conditions to the IOA Conditions file are:

• IOA utility IOACND

• IOA online Conditions Resources screen (Screen4)

• IOA ISPF utility I1

• From the Control-M Active Environment, Screen3.?

Examples using the above facilities can be found in the Control-M for z/OS User Guide and the INCONTROL for z/OS Utilities Guide.

Step 3 – Creating UNIX job definitions

Using Control-M/Desktop, define a UNIX job with an IN condition PRDOS390-ENDED, so the job will be submitted only after the successful execution of the z/OS job PRDOS390.

Cross-platform jobs, managed by Control-M/EM, trigger z/OS jobs

Task Description

Schedule a UNIX job (PRDUNIX) in Control-M for UNIX that sets a global OUT condition upon ending OK which, in turn releases a z/OS job for execution.

Using Control-M/Assist, z/OS jobs are captured only after they are submitted and arrive on the JES spool. The z/OS job's JCL must include the JOB parameter TYPRUN=HOLD so that any IN conditions in the job definition can be used for purposes of releasing the job for execution (since the jobs were already submitted). After submission the jobs wait on the JES held queue and are released only after all scheduling runtime criteria of the job are satisfied.

Step 1 – Defining Global Condition prefixes

Using the Control-M/EM Global Conditions Window, add a new global prefix PRDUNIX.

In the 'From' area select the Control-M for UNIX installation, and in the 'To' area select the Control-M for z/OS installation. After clicking OK the definition will be added. Every condition starting with prefix PRDUNIX and originating on the UNIX environment will automatically be added to the Control-M for z/OS environment.

Step 2 – Creating z/OS CMEM RULE and job definitions

We can use the previously prepared CMEM rule definition, PRD*, to capture all job arrival events and to force their job definition to the active job file. This rule captures the arrival of job PRDOS390.

Create a new job definition PRDOS390. To the definition add an IN condition PRDUNIX-ENDED. The definition will be automatically forced to the Active Jobs File only after the job is submitted and the CMEM rule is triggered which forces its definition.

The job's JCL JOB statement must contain parameter TYPRUN=HOLD, otherwise the job will start executing immediately upon submission.

Step 3 – Creating UNIX job definitions

Using Control-M/Desktop, define a UNIX job. The UNIX job adds an OUT condition PRDUNIX-ENDED, to trigger the z/OS job PRDOS390.