Control-M JCL Verify Monitor

The Control-M JCL Verify monitor enables the user to locally or remotely process JCL jobs with site standards, reformatting, and enforcement rules.

This chapter includes the following topics:

Overview

The Control-M JCL Verify monitor enables the user to locally or remotely process JCL jobs by loading the monitor with site related information, site standards, reformatting rules, and enforcement rules.

Since, in certain respects, the JCL processing might be influenced by the user's environment, the results might not be fully applicable to every environment. Using the Control-M JCL Verify monitor can solve this issue, since the system and IOA environment where the job is intended to run can be specified, so that the JCL processing can be performed remotely and accurately.

The local Control-M JCL Verify monitor, where Control-M JCL Verify is installed, communicates with the remote Control-M JCL Verify monitors. Within a SYSPLEX, communication is through Cross-system Coupling Facility (XCF). Between SYSPLEXs, communication is through IOAGATEs and the Control-M JCL Verify Application Server.

In addition, the monitor enables

  • JCL verifications in a non-APF authorized environment

  • application of site standards

  • JCL reformatting and enforcement

The monitor activates the CTJINIT utility functions, which are only accessible through the monitor.

Monitor concepts

Monitor location

For remote JCL processing, a monitor must be running on the system and IOA environment where the JCL exists. A monitor must also be running on the node, system, and environment where the results are to be sent. Only one monitor can run on a particular system - IOA environment combination. Any additional monitors that are started on that system - IOA environment combination, will be terminated with an error message.

Local monitor

The Control-M JCL Verify monitor running on the same system and belonging to the same IOA environment as the end user is called the local Control-M JCL Verify monitor. All communications with the end user is implemented through its local monitor. The local monitor receives all requests that must be handled by the monitors. The local monitor might handle the request itself or it might send it on (by means of a remote request) to another target monitor. After the request is processed, the results are sent back to the end user. If the request was processed by the local monitor, it sends the results directly to the end user. The results of remote requests (processed by a monitor other than the local one) are passed to the end user through the local monitor.

The communication between the end user and the local monitor uses cross memory services (synchronized data passing between different address spaces - for example, between TSO logon and Control-M JCL Verify monitor) of the same z/OS. For example, when a local monitor receives JCL verification requests from an end user, it executes the requests, and then returns the results back to the user through cross memory services.

Remote verification

Inter-monitor communication for remote verification

In this section, the term "remote verification" is used to include the following: remote verification, enforcement and reformat processing.

Intra SYSPLEX diagram

A remote verification request can be sent from any Control-M JCL Verify monitor (CTJMON) in the SYSPLEX to any other CTJMON in the same SYSPLEX, without any special set up and without an IOAGATE. Using XCF, a CTJMON in a SYSPLEX can communicate automatically with any other CTJMON in the SYSPLEX.

For remote verification between different SYSPLEXs, at least one IOAGATE/CTJAS (Control-M JCL Verify Application Server) pair is needed to connect the two SYSPLEXs to each other. In the more general configuration with multiple SYSPLEXs, remote verification requests can be sent from any CTJMON in a SYSPLEX to any other CTJMON in another SYSPLEX with only a single IOAGATE/CTJAS per SYSPLEX.

All CTJMON’s with the same XCFGROUP definition in CTJPARM can discover and communicate with each other. By default, XCFGROUP is the same for all installations and versions. However, if required, CTJMON’s can be grouped into distinct groups by defining a unique XCFGROUP for each group.

Remote Verification between SYSPLEXs diagram

CTJMON in one SYSPLEX can communicate with CTJMON in another SYSPLEX if there is a pair of IOAGATE/CTJAS that connect the two SYSPLEXs. Only a single IOAGATE/CTJAS pair (one in each SYSPLEX) is required to enable all CTJMONs in one SYSPLEX to communicate with all CTJMONs in the other SYSPLEX.

For example, in order for CTJMON in SYSB in PLEX1 to communicate with CTJMON in SYSD in PLEX2, CTJMON in SYSB will use XCF to forward the request to the CTJMON in SYSA (the CTJMON which contains the IOAGATE/CTJAS pair) and then CTJMON in SYSA will forward the request via its associated IOAGATE/CTJAS to the IOAGATE/CTJAS in SYSE in PLEX2. This IOAGATE/CTJAS will forward the request to the CTJMON in SYSE, which in turn will forward the request, using XCF, to the target CTJMON in SYSD. The reply will come back over the same route.

Defining the target CTJMON where the processing will be submitted

To specify where the processing will be submitted, use the following parameters:

Tab.JV.3.1 CTJMON routing parameters

Parameter

Description

NODE=IOAGATEnode

Identifies the target SYSPLEX by specifying the NODE of the IOAGATE that runs in the target SYSPLEX. This IOAGATE must be connected to the IOAGATE in the LOCAL SYSPLEX. When the target SYSPLEX is the local SYSPLEX, this parameter can be omitted.

NODE=LOCAL also specifies the local SYSPLEX.

The verification request is forwarded to the CTJMON associated with the IOAGATE/CTJAS with the given NODE. The request might be forwarded to another CTJMON depending on the SYSTEM and IOA ENV parameters.

Default: A blank indicates the local SYSPLEX and XCF Group.

Masking is not supported.

SYSTEM=system

Identifies the target SYSTEM in the target SYSPLEX.

Default: A blank indicates any SYSTEM in the target SYSPLEX.

Preference is given to SYSTEM with the same name as the originating SYSTEM, when IOA ENV is not blank or *.

Masking: * has the same meaning as blank

IOA ENV=ioa_env

Identifies the target CTJMON by the QNAME of the IOA environment in the target SYSPLEX/SYSTEM.

Default: A blank specifies any IOA environment in the target SYSPLEX. Preference is given to the IOA environment that is the same as the originating CTJMON when SYSTEM is not blank or *.

Masking: * has the same meaning as blank

AR=Y|N|D

Specifies whether Auto Routing will be enabled (Y) or not (N) or whether the default (D) Auto Routing will be used.

Auto Routing is not supported under the CTJPLAN and CTJMRFLW utilities.

The NODE name parameter can be defined in the requests that are sent to the Control-M JCL Verify monitor. This NODE name is defined in the network map member (defined by the NETWMAP= parameter in the ECAPARM<suffix> member). The NODE name identifies the target Control-M JCL Verify monitor. An undefined NODE name returns an error message without starting the JCL processing procedure.

The NODE, SYS, and IE names can be defined in the following types of JCL processing requests and user interfaces:

  • CTJVER procedure parameters

  • CTJXVER edit macro (when it is invoked with the P option)

    Copy 
    ---------------   CONTROL-M JCL VERIFY DEFINITION FACILITY  ---------------
    ENTER THE PARAMETERS BELOW:
    MEMBER =>           LIBRARY =>        
    USER=>          PROCDD=>          LINKDD =>                          
    NODE=>          SYSTEM=>          IOA ENV=>          AUTO ROUTE=> D (Y/N/D)
    Sample start of the output report of a remote verification request under CTJXVER:
      Control-M JCL Verify IS STARTING. LEVEL BJ10387                        
      REQUEST RECEIVED  BY MONITOR J90MON   ON SYSTEM MVS3                   
      REQUEST EXECUTED  BY MONITOR J90MON9  / JOB00228 ON SYSTEM MVS1         
      RUNTIME PARAMETERS: FA=Y FV=Y JES=Y ME=Y ML=I CTM=N STDR=Y UT=Y        
                          ENV=REXXRC   USER=M49A                             

    The messages that indicate which CTJMON received the request from the user and which CTJMON executed it.

  • 'JD' screen - JVER Definition Facility. It can be used for sending Online JVER requests (from '2', '3' or JV screens) to be handled by the Control-M JCL Verify monitor.

    Copy 
    ------------ CONTROL-M/JCL VERIFY DEFINITION FACILITY - ENTRY PANEL -------
    (JD)COMMAND ===>                                                                   
                                                                                   
    ENTER PARAMETERS BELOW                                                         
        PROCDD=>          LINKDD=>                                                 
        NODE=>          SYSTEM=>          IOA ENV=>          AUTO ROUTE=> D (Y/N/D)

The following Control-M JCL Verify components and requests are only handled by local monitors, they cannot be invoked in target systems nor send requests to other Control-M JCL Verify monitors:

  • JCL verification request on Control-M/Enterprise Manager

  • CTJAPI Macro (Control-M JCL Verify Application Program Interface) does not need the NODE parameter. CTJAPI is invoked in the environment and address space which handles Control-M JCL Verify verification requests. So Control-M JCL Verify monitor subtask can issue CTJAPI to perform JCL verification.

The three target parameters can be defined in the following types of JCL processing requests and user interfaces:

  • CTJVER, CTJENR, CTJMRFLW utility and CTJPLAN utility: procedure parameters (only the NODE can be specified)

  • CTJVER, CTJENR, CTJMRFLW and CTJPLAN: SYSIN DD  * parameters (all three parameters can be specified) as follows:

    Copy 
      CTJVER,CTJENR: //SYSIN DD *
      CTJMRFLW,CTJPLAN: //JVER.SYSIN DD *
      NODE=<node>
      IE=<IOA env> SYS=<system>
      LIB=<library>   MEM=<member>    

    Following is a sample of the beginning portion of the output report for a verification request in batch:

    Copy 
    CTJU00I Control-M/JCL Verify Utility started. Date/Time 30.04.17 / 17:52. Level 9.0.03    WJ10028 
    CTJU01I FA=D FV=D JES=D ME=D ML=D STDR=D ENV=GENERAL CTM=D UT=D NODE=LOCAL  
    CTJU01I  NODE=TLV1                                                                                        
    CTJU01I  SYSTEM=MVS1                                                                                      
    CTJU01I  LIB=M49.SRC               MEM=M49BR144                                                           
    CTJ000I Control-M/JCL Verify is starting. Level BJ10387                                                   
    CTJM36I Request received  by monitor J90MON   on system MVS3                                              
    CTJM0DI Request executed  by monitor J90MON9  / JOB00228 on System MVS1                                   
    CTJ00CI Runtime parameters: FA=Y FV=Y JES=Y ME=Y ML=I CTM=Y STDR=Y UT=Y ENV=GENERAL  USER=M49A 

The CTJM36I message, which indicates the CTJMON that received the request from the user, and the CTJM0DI message, which indicates the CTJMON that executed it.

For CTJMRFLW and CTJPLAN, the parameters are specified in the SYSIN DD * of the verification step as follows:

Copy 
//CTJMRFLW  JOB 0,CTJMRFLW,CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID, 
//       MSGLEVEL=(1,1)
//   SET IOA=IOAA.V93J4
//*
//         JCLLIB  ORDER=&IOA..PROCLIB
//         INCLUDE MEMBER=IOASET
//*--------------------------------------------//JVERFLW  EXEC CTJMRFLW,FA=Y,FE=Y,ME=Y,
//            ODATE=170418
//JOBLIST.DAJOB DD *
 ORDER DSN=CTJA.CTJMRFLW.SCHEDULE  MEMBER=DEPAW087
//JVER.SYSIN    DD *
   NODE=NODE1 SYS=MVS1 IE=V93J1
//      DD  DISP=(SHR,DELETE),DSN=&&PARMJV(JVERIN)
//  
//CTJPLAN  JOB 0,'CTJPLAN_TODAY',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID, 
//  USER=JUA
// SET ILPREFA=IOAA.V93J4    %%ILPREFA
// JCLLIB ORDER=&ILPREFA..PROCLIB
// INCLUDE MEMBER=IOASET
//JCLVRFY EXEC CTJPLAN,ODATE=111217,NODE=LOCAL
//SCHEDLIB DD DISP=SHR,DSN=QUEST.JVER.SCHEDULE.R
//DACAL    DD DISP=SHR,DSN=QUEST.JVER.CTJPLAN.CAL
//*        DD DISP=SHR,DSN=&ILPREFA..OPR.CAL
//SYSIN DD *
TABLES CURRENTD,WEEKDAYS
//JVER.SYSIN DD *
  SYS=MVS1 IE=V93J1
//     DD DISP=(OLD,DELETE),DSN=&RPLAN          

IOAGATE node names

Each IOAGATE/CTJAS has a unique NODE NAME associated with it. The node name is defined in the ECAPARM member of IOAGATE/CTJAS.

For more information about IOAGATE NODEs, see IOAGATE Nodes.

Auto Routing

Control-M JCL Verify can analyze the JCL and adjust the routing criteria so the JCL will be verified on a different Control-M JCL Verify monitor or system, according to JES commands or JOB card routing keywords. Note that only verification can be performed with Auto Routing.

Auto Routing is disabled in the following cases:

  • The member contains multiple jobs.

  • The request is for verifying an entire library.

  • Multiple members are specified in CTJVER SYSIN.

In all these cases, Auto Routing is deactivated and the verification is performed locally.

Auto Routing is supported for

  • CTJVER utility for regular JCL and Control-M schedule definitions. See parameter AR in Parameters (in the INCONTROL for z/OS Utilities Guide).

  • CTJXVER edit macro, see parameter AUTO ROUTE in Verification mode.

Parameter to enable Auto Routing:

AR= Whether to enable Auto Routing.

Valid values are:

  • Y - Yes

  • N - No

  • D - as Defined by the AROUTE parameter in the CTJPARM

Auto Routing monitor types

The Control-M JCL Verify monitor which receives the processing request directly from the user is called the Receiver monitor.

The Receiver monitor routes the request, according to the routing parameters (NODE, SYS, or IE) provided by the user, to the Submission monitor, which processes the JCL, checking what would be the results if the JCL would be submitted on the target system. The Submission monitor resolves the Control-M AutoEdit variables.

If Auto Routing is enabled in the request, the Submission monitor then analyzes the JCL for JES routing commands or JOB card keywords that provide instructions for forwarding the JCL to another JESPLEX or SYSTEM for execution. If the JCL includes routing instructions, the Submission monitor routes the JCL to the correct monitor on the target JESPLEX/SYSTEM.

The final monitor where the JCL is fully processed is called the Execution monitor.

The following log report messages indicates the three different types of monitors:

  • Receiver monitor

    • CTJM36I Request received by monitor XXXXXXXX on system XXXXXXXX

  • Submission monitor

    • CTJM37I Request submitted by monitor XXXXXXXX on system XXXXXXXX

  • Execution monitor

    • CTJM0DI Request executed by monitor XXXXXXXX / XXXXXXXX on System XXXXXXXX

If AUTOROUTE=Y and one of the routing parameters (NODE, SYS, or IOAENV) is specified then remote verification can be performed by two remote CTJMONs as follows:

  • In the SUBMIT SYSTEM where the JOB will be submitted.

    If CTM AutoEdit and JCL modification is requested, it will be performed by the CTJMON on the SUBMIT SYSTEM.

    Minimal JCL checks are performed by the CTJMON on the SUBMIT SYSTEM to find out whether it is also the final EXECUTE SYSTEM or not.

    If not, it is validated that the JCL will not fail during submission.

  • In the EXECUTE SYSTEM where the JOB will be executed.

    Full JCL verification is performed by the CTJMON on this system.

The NODE, SYSTEM, and IOAENV parameters specified by the user in the JCL Verify request, define the SUBMIT SYSTEM where the given JCL will be submitted. Control-M JCL Verify first sends the given JCL to the CTJMON that is associated with the IOAGATE with the mapped IOAGATE NODE name. This CTJMON forwards the request to the target CTJMON in the same SYSPLEX based on the SYSTEM and IOAENV parameters.

When AUTOROUTE=N, the target CTJMON is the final target that will perform the verification request.

Auto Routing based on JES nodes

To enable Control-M JCL Verify to support JES node commands, the CTJJ2G member must be defined as described in CTJJ2G - JES Nodes to CTM/JCL Verify Gateway Nodes Association.

The following JES2 commands are supported for Auto Routing:

Copy 
/*XMIT
/*ROUTE XEQ
/*XEQ

The following JES3 command is supported for Auto Routing:

Copy 
//*ROUTE XEQ

The following JCL command is supported for Auto Routing based on JES nodes:

Copy 
//   XMIT  DEST=<node>

Each JES command is processed as follows:

  1. The JES node name, JES node number, or JES DESTID is extracted.

  2. The JES node number or JES DESTID is translated to a JES node name.

    1. If there is a Control-M JCL Verify monitor with the given JES node in the local XCF group, send the request to the JES node via XCF.

    2. Lookup the JES node name entry in the CTJJ2G member to obtain the IOAGATE node name.

    3. If the JES node name is not found in the CTJJ2G member, and the CTJPARM parameter J2GUSEJ is set to Y, use the JES node name as the IOAGATE node name.

  3. Send the JCL to the correct monitor through the IOAGATE and XCF as described in Inter-monitor communication for remote verification.

Auto Routing based on system identification

When Control-M/JCL Verify detects both JES node routing commands and system identification routing keywords, Control-M/JCL Verify first routes the JCL according to the JES node commands and then the JCL is analyzed a second time to determine, according to the system identification keywords, on which monitor the JCL will be verified.

Control-M/JCL Verify monitor can Auto Route a request to a specific system within a JESPLEX, through XCF only, based on a combination of parameters in the JOB and in the JES statements. The routing logic attempts to emulate JES2/JES3 processing.

Auto Routing uses the following keywords for the target system identification:

  • JOB SCHENV

  • JOB SYSTEM, SYSAFF

  • JOB CLASS

  • /*JOBPARM S, SYSAFF

  • //*MAIN SYSTEM

  • //*MAIN CLASS

The system chosen for verification must have an active CTJMON in the same XCFGROUP and JESPLEX. If the submission system successfully passes the selection process described below, it has priority over any other system and will be used for the verification. If there is no system that successfully passes the selection process, by default the submission system will be used for the verification.

In order to determine which system the JCL will be verified on, the Auto Routing process attempts to create three separate lists of candidate systems based on the following parameters:

  • SCHENV (obtained from the JOB or CLASS)

  • SYSTEM or SYSAFF (obtained from the JOB or from //*MAIN or /*JOBPARM)

  • CLASS (obtained from the JOB or //*MAIN or from the default CLASS)

If the SCHENV is invalid, Auto Routing is disabled (since the job would anyway result in a JCL error) and the verification is performed on the submission system.

The systems where the scheduling environment is active are included in the SCHENV list of candidate systems.

If the scheduling environment is not active anywhere, the SCHENV parameter is ignored and the selection process will continue with the other parameters.

The systems specified by the SYSTEM or SYSAFF parameters are used to create another list of candidate systems. These parameters will not be ignored.

If the list of these systems has no systems in common with the list of systems created by the SCHENV parameter,  the SCHENV parameter will be ignored.

The third list of systems is created using the CLASS parameter. The candidate systems are selected where the specified CLASS is currently active, enabled, and supports a maximum number of jobs greater than 0. For non-WLM classes, the CLASS must have either an active or an inactive initiator on the system.

If there are no systems where the CLASS requirements are fulfilled, the CLASS parameter will be ignored.

If the list of systems that fulfill the CLASS requirements has no systems in common with the combined list of systems created by the SCHENV and SYSTEM or SYSAFF parameters,  the CLASS parameter will also be ignored.

CTJVER Batch example:

Copy 
//JCLVER    JOB                                     
//         JCLLIB  ORDER=(IOA.V900.PROCLIB)         
//         INCLUDE MEMBER=IOASET                    
//JCLVER    EXEC CTJVER                             
//SYSIN    DD   *                                   
 SYS=MVS1   AR=Y                                    
 LIB=CTJA.JCL.NET           MEM=NODEM033            

CTJVER Batch output report:

Copy 
********************************* TOP OF DATA **********************************
CTJU00I Control-M/JCL Verify Utility started. Date/Time 08.05.17 / 13:14. Level 
CTJU01I FA=D FV=D JES=D ME=D ML=D STDR=D ENV=GENERAL CTM=D UT=D NODE=LOCAL      
CTJU01I  SYS=MVS1  AR=Y                                                         
CTJU01I  LIB=CTJA.JCL.NET           MEM=NODEM033                                
CTJ000I Control-M/JCL Verify is starting. Level BJ10387                         
CTJM36I Request received  by monitor J4JMON   on system MVS4                    
CTJM37I Request submitted by monitor J1JMON   on system MVS1                    
CTJM0DI Request executed  by monitor J7JMON   / S0267759 on System MVS9         
CTJ00CI Runtime parameters: FA=Y FV=Y JES=Y ME=Y ML=I CTM=Y STDR=Y UT=Y ENV=GENE
CTJM38I Routing parameters: NODE=        SYS=MVS1     IE=         AR=Y
        ************************************************************************
CTJ002I * Start processing MEMBER=NODEM033    JOBNAME=NODE0032                 *
CTJ008I *                  DSNAME=CTJA.JCL.NET                                 *
        ************************************************************************
                1 //NODE0032 JOB 00122XP2,KLIEMCHEN,CLASS=9,LINES=1000,MSGCLASS=
CTJR05I           //         SYSTEM=MVS9                                        
                  //         SYSTEM=MVS9,                                       
                  //       MSGLEVEL=(1,1),                                      
                  //       UJOBCORR='CTM_$UNKNWN$_00000'                        
CTJ00SI         1 RULE-INFO:  SAMPLE RULE ONLY                                  
                2 //I EXEC PGM=IEFBR14                                          
CTJP0GI         2 INFORMATION: PGM IEFBR14  found in LINKLIST SYS1.LINKLIB      
                3 //SYSIN DD DATA,DLM=##                                        
                  //*                                                           

The monitor which receives the request is MVS4. Since SYS parameter is set to MVS1 in the SYSIN, Control-M JCL Verify routes the JCL to MVS1, and while analyzing the JCL on the monitor which run on MVS1, it encounters the keyword SYSTEM=MVS9 and since AR is set to Y, Control-M JCL Verify on MVS4, routes the JCL to the MVS9 system, and the Control-M JCL Verify monitor there executes the verification. Note the messages which indicate the routing process.

CTJXVER Edit Macro Example

CTJXVER Edit Macro in the P panel:

  • SYSTEM parameter is set to MVS1

  • AR parameter is set to Y

Parameters panel:

Copy 
---------------   CONTROL-M JCL VERIFY DEFINITION FACILITY  ---------------
ENTER THE PARAMETERS BELOW:                         SAVE CHANGES => N (Y/N)
MEMBER => NODE0033  LIBRARY => CTJA.JCL.NET                                
USER=> K68                                                                 
NODE=>          SYSTEM=> MVS1     IOA ENV=>          AUTO ROUTE=> Y (Y/N/D)
SUMMARY FORMAT ===> D  (T/M/N/D)    T - TABLE  M - MESSAGES  N - NO SUMMARY
MESSAGE ID     ===> D  (Y/N/D)      Y - SHOW MSGID  N - HIDE MSGID         
RULE TRACE     ===> D  (Y/N/D)      SHOW TRIGGERED RULE INFORMATION                  
SPECIFY VERIFICATION CRITERIA:                                             
JES SYNTAX                           ==> D  (Y/N/D)                        
DATASET VERIFICATION                 ==> D  (Y/N/S/U/D)                    
DATASET AUTHORIZATION                ==> D  (Y/N/D)                        
PROGRAM EXISTENCE                    ==> D  (Y/N/D)                        
RESOLVE CONTROL-M AUTO-EDIT VARIABLE ==> D  (Y/N/D)  ODAT=>        (YYMMDD)
SITE STANDARDS RULES                 ==> D  (Y/N/D)  ENV => GENERAL        
UTILITIES VALIDATION                 ==> D  (Y/N/D)                        
MESSAGES LEVEL                       ==> D  (I/W/E/D)                      
SAVE REPORTS  ==> N  (Y/N/D)  Y-SAVE  N-NO SAVE  D-DEFAULT VALUES (CTJPARM)
JREPPREF =>                     JREPVOL =>        JREPUNIT ==>             
                                                                            
 Y - ALWAYS CHECK  N - NEVER CHECK  S - NO SPACE CHECK  U - UTILITIES CHECK
 E - ERRORS        W - WARNING      I - INFORMATION     D - DEFAULT        
PRESS ENTER TO CONTINUE, END OR PF03/PF15 TO EXIT                          

Control-M JCL Verify Edit Macro report:

Copy 
***************************** Top of Data ******************************
 CONTROL-M/JCL VERIFY IS STARTING. LEVEL BJ10387                        
 REQUEST RECEIVED  BY MONITOR J4JMON   ON SYSTEM MVS4                   
 REQUEST SUBMITTED BY MONITOR J1JMON   ON SYSTEM MVS1                   
 REQUEST EXECUTED  BY MONITOR J7JMON   / S0267759 ON SYSTEM MVS9        
 ROUTING PARAMETERS: NODE=        SYS=MVS1     IE=         AR=Y
 RUNTIME PARAMETERS: FA=Y FV=Y JES=Y ME=Y ML=I CTM=Y STDR=Y UT=Y        
                     ENV=GENERAL  USER=K68                              
                                                                        
 JOB VERIFICATION COMPLETED WITH                                        
      0 ERROR MESSAGES                                                  
      0 WARNING MESSAGES                                                
      2 INFORMATION MESSAGES                                            
                                                                        
----------------------  VERIFICATION SUMMARY  --------------------------
LABEL      MSGID    MESSAGE                                             
------------------------------------------------------------------------
.BAAA      CTJ00SI  RULE-INFO:  SAMPLE RULE ONLY                        
.BAAB      CTJP0GI  INFORMATION: PGM IEFBR14  FOUND IN LINKLIST         
                    SYS1.LINKLIB                                        
----------------------  VERIFICATION SUMMARY END  ----------------------
                                                                        
//NODE0032 JOB 00122XP2,KLIEMCHEN,CLASS=9,LINES=1000,MSGCLASS=X,        
//         SYSTEM=MVS9                                                  
//         SYSTEM=MVS9,                                                
//       MSGLEVEL=(1,1),                                               
//       UJOBCORR='CTM_$UNKNWN$_00000'                                 
 CTJ00SI  RULE-INFO:  SAMPLE RULE ONLY                                  
//I EXEC PGM=IEFBR14                                                    
 CTJP0GI  INFORMATION: PGM IEFBR14  FOUND IN LINKLIST SYS1.LINKLIB      
//SYSIN DD DATA,DLM=##                                                  
//*                                                                     

The monitor which receives the request is MVS4. Since the SYS parameter is set to MVS1 in the P parameters window, Control-M JCL Verify routes the JCL to MVS1, and while analyzing the JCL on the monitor which runs in MVS1, it encounters the keyword SYSTEM=MVS9 and since AR is set to Y, Control-M JCL Verify at MVS4, routes the JCL to system MVS9, where the Control-M/JC Verify monitor there executes the verification. Note the messages which indicate the routing process.

Displaying the configuration

The modify command F CTJMON,XCF will show the members in the XCF GROUP.

Copy 
CTJM1FI XCF GROUP: CTJMON93  STATUS: ENABLED
CTJM1GI SYSTEM   IOA ENV  IOAGATE  JES NODE
CTJM1HI -------- -------- -------- --------
CTJM1HI MVS3     IOAR900           NODE3
CTJM1HI MVS9     IOAR900  TLV9     NODE3
CTJM1II END                                       

In the above display, there are two CTJMONs in the SYSPLEX which belong to XCF GROUP CTJMON93, one on MVS3 and another on MVS9. The IOA environments of both are IOAR900.

The JES NODE name of both MVS3 and MVS9 is NODE3.

IOAGATE with NODE name TLV9 runs on MVS9 and is associated with CTJMON on MVS9.

The F IOAGATE,MAP command will show which remote NODEs are connected to IOAGATE.

For example, F IOAGATE,MAP to the corresponding IOAGATE above in MVS9 shows:

Copy 
ECAP20I IOAGATE-TO-JVER    TCP CONNECTIONS NODE=TLV9     MAP=MAPJVE8  APPL=JVERE
CAP23I CHAN TASK PARTNER  PORT  CONNECTOR S T A T U S  SOCKET    HOST
ECAP24I ---- ---- -------  ----- --------- -----------  ------    ----
ECAP24I MCJ1   03 TLV1           PARTNER   CONNECTED         1    ::ffff:172.24.49.64
ECAP24I MCJ1      TLV8           PARTNER   WAITING FOR CONNECTION               

We can see that this is IOAGATE with NODE=TLV9.

This IOAGATE is currently connected to IOAGATE with NODE TLV1.

This means that all CTJMONs in the remote SYSPLEX where IOAGATE with NODE=TLV1 runs are available for remote verification. (They have to be in the same XCF GROUP as the CTJMON associated with the remote IOAGATE).

It is recommended to define IOAGATE NODE names that indicate the SYSPLEX where the IOAGATE is located.

Backwards compatibility

A later version of CTJMON can send verification requests to an earlier version of CTJMON + IOAGATE/CTJAS. The request will be performed by the CTJMON associated with the earlier version of IOAGATE/CTJAS. Only the NODE parameter can be used in such requests. The SYSTEM and IOA ENV can be omitted and if specified they will be ignored.

An earlier version of CTJMON + IOAGATE/CTJAS can send verification requests to a later version of CTJMON + IOAGATE/CTJAS. The request will be performed by the CTJMON associated with the later version IOAGATE/CTJAS. Only the NODE parameter can be specified and used in such requests.

Loading site related information

Using Control-M JCL Verify monitor ensures that the JCL processing takes into account the site related information and rules. When starting, Control-M JCL Verify monitor invokes the REFRESH,SCOPE=ALL function that loads the site related information and site standards, reformatting and enforcement rules into a shared object allocated in "above the bar" memory.

While running, the Control-M JCL Verify monitor accepts MODIFY operator commands that control the loading and removing of site related information, using the following format:

Copy 
F CTJMON,REFRESH|REMOVE|REMOVEF,SCOPE=ALL|RULES

The abbreviations REF/REM/REMF can be used instead of the REFRESH / REMOVE / REMOVEF keywords.

For more information, see Improving Performance.

Passing data to monitors

In most the cases, JCLs and schedule definitions are passed to Control-M JCL Verify monitors using the names of the corresponding libraries and members. When the Control-M JCL Verify verification is requested from the editing or changing dialog, then the contents of the JCL or schedule definition is transferred instead, because the data was probably changed by the user and might not be saved yet.

Passing data by the names of the JCL and schedule definition libraries and members requires that these datasets must be accessible in the system where the Control-M JCL Verify verification is to be performed (the system where the target Control-M JCL Verify monitor is running). This is also relevant for the datasets referenced by the members and definitions required by Control-M JCL Verify verification, for example JCL libraries defined in the corresponding schedule definitions.

Security protection

When Control-M JCL Verify Monitor handles a JCL verification request, and IOA Security is activated, the monitor uses the Security Access Environment (Access Authority Profile) of the user ID requesting the verification. This security arrangement ensures that the Control-M/JCL Verification process is limited to the access rights of the corresponding user ID (TSO logon, batch job, or IOA Online Monitor session) outside the Control-M JCL Verify Monitor. The user ID, requesting the JCL verification, is passed to the Control-M JCL Verify Monitor together with other data describing the verification request, such as which job(s) or JCL(s) are to be verified and other various verification parameters.

Security Access Environment Elements (for users requesting verifications) are created by the Control-M JCL Verify Monitor and saved in a cache maintained by the monitor. Additional requests from the same user do not require the creation of new elements, since the elements for that user are available from the cache. The NEWSECDEF modify command for Control-M JCL Verify Monitor can be issued to refresh the Security Access Environment Elements in cache, without stopping and restarting the monitor.

When a JCL verification request is received from a remote node (that is, a verification request from a Control-M JCL Verify monitor running on an LPAR other than the local one) and the user ID, which issued the verification request from the remote node, is undefined in the local security system, the Control-M/JCL Verification installation parameter RMTUSER can be used instead of the requestor user ID. For more information about the RMTUSER installation parameter, see the INCONTROL for z/OS Installation Guide: Installing.

Monitor command summary

The valid Control-M JCL Verify monitor MODIFY operator commands are listed below.

Tab.JV.2.1 Valid MODIFY operator commands

Command

Description

REFRESH
REF

Loads site related information. For more information, see the "Functions used for loading and removing site information" table in Improving Performance.

REMOVE
REM

Removes site related information. For more information, see the "Functions used for loading and removing site information" table in Improving Performance.

REMOVEF
REMF

Forcefully removes site related information. For more information, see the "Functions used for loading and removing site information" table in Improving Performance.

NEWSECDEF

Dynamically refreshes the Security Access Environment Elements (created for users requesting verifications and saved in the cache) without stopping and restarting the Control-M JCL Verify Monitor.

TRACE

Activates or disables diagnostic traces.

XCF

Displays the status of the XCF group and the following information for each member in the group: system name, IOA environment name, IOAGATE node name and JES node name.

TERM

Terminates all the verification requests that are being processed, without bringing down the monitor. This command can be used when a STOP ctjmon command fails because there are active sessions.

LISTVSUM

Prints out a summary of storage memory allocations. The results can be seen in the DAPRENV statement.

LISTVDET

Prints out a detailed map of storage memory allocations. The results can be seen in the DAPRENV statement.

HELP

Displays the list of valid MODIFY commands.