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=M49AThe 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:
CopyCTJVER,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:
CopyCTJU00I 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:
//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:
/*XMIT
/*ROUTE XEQ
/*XEQ
The following JES3 command is supported for Auto Routing:
//*ROUTE XEQ
The following JCL command is supported for Auto Routing based on JES nodes:
// XMIT DEST=<node>
Each JES command is processed as follows:
-
The JES node name, JES node number, or JES DESTID is extracted.
-
The JES node number or JES DESTID is translated to a JES node name.
-
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.
-
Lookup the JES node name entry in the CTJJ2G member to obtain the IOAGATE node name.
-
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.
-
-
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:
//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:
********************************* 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:
--------------- 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:
***************************** 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.
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:
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:
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 |
Loads site related information. For more information, see the "Functions used for loading and removing site information" table in Improving Performance. |
REMOVE |
Removes site related information. For more information, see the "Functions used for loading and removing site information" table in Improving Performance. |
REMOVEF |
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. |