Control-M/Assist vs. Control-M for z/OS functionality

This chapter includes a comparison of the functionality available when using Control-M as the main scheduler in the z/OS environment, as opposed to the limited functionality Control-M/Assist provides.

This chapter gives a brief overview of the limited range of functionality of the Control-M/Assist solution as opposed to a fully implemented Control-M environment. We will use the GUI features available in Control-M/EM as the basis of our comparison.

Control-M/Assist consists of the following components: Control-M for z/OS, CMEM, Control-M Application Server, IOAGATE and Control-M/EM.

The Control-M/Assist solution is designed for customers who have chosen to purchase the Control-M distributed systems solution and wish to utilize Control-M/EM as the overall GUI from which to control and track the entire scheduling environment across all platforms (including the z/OS environment) but still want to retain a non-Control-M mainframe scheduling product.

First we discuss the limitations of Control-M/Assist.

• Job definition maintenance

  Using CMEM, Control-M for z/OS can track jobs that have been submitted to MVS external to Control-M. This is accomplished by creating Control-M job scheduling definitions and corresponding CMEM rules which allows proper tracking under Control-M/EM. Hence, jobs for which Control-M/EM tracking is desired must be defined in CMEM and Control-M (or Control-M/Desktop).

  To minimize the number of definitions that must be created, the Control-M and CMEM generic definition facility (see Monitoring all production jobs (PRD*)) should be utilized, thereby reducing the overhead of redefining the work logic contained in the customer's native scheduling product.

• Using IOA and Control-M utilities

  Another area in which the Control-M mainframe component cannot be treated as a 'black box' is in the use of IOA and Control-M utilities. To realize the full potential of Control-M and to ease in its implementation, several utilities should be utilized. For example, utility CTMBLT can be used to build tables in batch, utility CTMTBUPD is useful in performing mass updates to the job scheduling definitions, utility IOACND can be used to add/delete/check conditions to the IOA Conditions files. The user should familiarize himself with the INCONTROL for z/OS Utility Guide and determine which utilities would be helpful in his implementation of Control-M/Assist.

• Handling jobs only after they are submitted

  Control-M/Assist handles jobs only after they are submitted and arrive on the JES spool, hence monitoring of jobs from the active environment (Screen 3) can only be done after jobs have been submitted.

  The Control-M/EM Viewpoint feature, which can be specified to filter the job list according to various criteria, is very similar to the Control-M for z/OS SHOW Filter capability (discussed in "Introduction to the active environment." However, with Control-M/Assist, the Viewpoint feature is limited to filtering jobs beginning with their appearance on the JES spool, that is, from the post-processing phase and onward. For example, filtering on job status WAIT SCHEDULE or WAIT SUBMISSION would be meaningless, unless the customer chooses to modify the JCL of his scheduling product jobs to specify TYPRUN=HOLD, in which case Control-M runtime criteria such as FROM/UNTIL time and IN conditions are relevant. Should the user choose to specify TYPRUN=HOLD, Control-M would not release affected jobs for execution until all their runtime criteria are satisfied. This would then provide greater filter capability in the Viewpoint feature.

  In addition to the TYPRUN=HOLD parameter, if the user requires that Control-M perform post processing tasks for the z/OS jobs, then the jobs must be submitted in a Control-M held SYSOUT class (specified in the MSGCLASS parameter). This may require additional JCL modification. For more details, see the description of the HLDCLAS parameter the INCONTROL for z/OS Installation Guide.

  No connection exists between the Control-M/Assist environment and the customer's scheduling product.

  Using the Control-M/Assist solution there is no connection or data flow between the customer's scheduling product and the Control-M/Assist environment. Control-M/EM manual Order or Force of job (equivalent to the actions available in the job definition screen, Screen 2) will only effect the Control-M/Assist environment and will not effect or update the customer's scheduling product environment.

  Control-M/EM permits users to add/delete/update conditions, control resources and quantitative resources. These services are not meaningful outside Control-M/Assist as there is no natural link from the IOA Conditions and Resources files to update the user's scheduling product.

  There are a host of actions that may be performed against jobs via Control-M/EM (parallel to options in Screen 3, Active Environment screen, in the mainframe environment). Some of these actions are not available or relevant for jobs within the Control-M/Assist framework.

  Below is a list of actions and whether these actions are available or meaningful for Control-M/Assist:

  • HOLD—Not available
  • CONFIRM—Not available
  • FREE—Not available
  • RERUN—Available, however, the user must ensure that the JCL submitted via the third-party-vendor scheduling product matches the Control-M MEMLIB parameter specified in the job scheduling definition
  • RESTART—Not available
  • REACT—Not available
  • DELETE—Not available
  • UNDELETE—Not available
  • KILL—Not available
  • FORCEOK—Not available
  • SYSOUT (View)—Available (only if Control-M/Restart is installed as part of the Control-M/Assist components)
  • STAT—Available (as long as the Control-M CTMJSA batch utility is run on a regular basis)
  • DOC—Not available (third-party-vendor scheduling product documentation may not be kept in PDS/member format, but in a database with record keys)
  • LOG—Semi-available (naturally, only actions on jobs performed from within ECS are recorded and not actions performed from third-party-vendor scheduling product)
  • VIEW JCL—Available, however, the user must ensure that the JCL submitted via third-party-vendor scheduling product matches the Control-M MEMLIB parameter specified in the job scheduling definition
  • EDIT JCL—Not available (since third-party-vendor scheduling product may maintain its own JCL repository database where modified job JCL members are placed)
  • WHY—Not relevant (all jobs are in post processing status). If TYPRUN=HOLD was specified for the job (see above), then the user can view which runtime criteria are not yet satisfied (according to the Control-M definition)
  • Properties —Available (zoom screen)

  Below are listed some additional limitations imposed by the use of Control-M/Assist besides those listed above:

  • No SMART Table support, since the CMEM rules are triggered by real external jobs which do not correspond to Control-M SMART Table Entities within tables
  • No support for enhanced NJE job tracking
  • JCL members cannot contain Auto-edit variables (neither local nor global)
  • Several job scheduling parameters are inoperative: SETVAR, SCHENV, SYSTEM-ID, NJE-NODE
  • No support for Control-M exit 2 (Submission) functionality. This includes any access security authorization checking done through exit 2.
  • Duplicate job definitions in Control-M tables are not supported.
• Customization of the Control-M environment

  In order to activate certain desired features the user may need to customize the installation of Control-M. Some typical examples of this are

  • IOA and Control-M exits for security processing, special shout handling, and so on
  • Modification of operational parameters (via the IOAPARM and CTMPARM members) to change default actions taken by the products

  For details on these activities, see the appendix about customizing INCONTROL products in the INCONTROL for z/OS Installation Guide, and the chapter about exits in the INCONTROL for z/OS Administrator Guide.