CMEM Diagnostic Tests

This section describes basic tests for locating installation problems in the Control‑M CMEM facility.

The CMEM facility requires the proper setup and functioning of the following major components:

• the Control‑M monitor (started task CONTROLM)
• one or more CMEM monitors (started tasks CTMCMEM). One CMEM monitor is normally required per CPU
• the Monitor-to-Subsystem file (M2S). This file passes requests from the Control‑M monitor to the CMEM monitors
• Subsystem-to-Monitor communication. Communication is established either through (S2M) files or the Sysplex Logger function

  This communication passes requests from the CMEM monitors to the Control‑M monitor. Using the file method, one Subsystem-to-Monitor (M2S) file is required for each CPU. The files are required if the Sysplex Logger is not in use.

Perform the tests only after the CMEM has been fully installed. Corrections to installation parameters can be made either manually in the corresponding members, or by using ICE.

1. Before testing, check that
   • parameters in member IOACPRM describe all CPUs in the complex, in addition to the names of the communication files or Logger structure
   • each communication file is uniquely named
   • either the communication files between the monitor and the subsystems have been allocated and formatted, or the Logger structure was allocated before the first CMEM or Control‑M

   This attribute is only available for Control‑O monitor starts.

   • an appropriate CMEM rule has been created, and either manually or automatically ordered by the CMEM monitor

     The most basic diagnostic test is to define a CMEM rule table so that when a certain job enters the system (that is, it is displayed on the reader), a condition is added for the same ODAT. For this basic test, it is recommend that you define a specific job name (do not use generic names with asterisks).

     An additional test is to define a CMEM rule table so that when a certain job enters the system (that is, it is displayed on the JES internal reader), a schedule table is ordered. For this test, the scheduling definition should contain one simple job definition.

   • the subsystem has been defined in SYS1.PARMLIB in all CPUs where CMEM must work (or SSALLOC=Y has been specified in member IOAPARM)
   • all provided fixes from BMC (with regard to CMEM functions) have been applied
   • if DSNEVENT or step events are to be monitored, check that JOBNAMES monitoring is turned on.

     You can use the following command to check the monitoring facility status that SETCON sets:

     D OPDATA,MONITOR

   • if DSNEVENT or step events are to be monitored, the MSGLEVEL parameter of all jobs, started tasks, or TSUs to be monitored contain the value 1

   For details about installation requirements to activate CMEM, see

   • the INCONTROL for z/OS Installation Guide: Installing
   • the INCONTROL for z/OS Security Guide
   • the JCL and AutoEdit facility chapter in the Control‑M for z/OS User Guide

   For information on changing CMEM-related parameters, see the INCONTROL for z/OS Installation Guide: Installing.

2. Stop the CMEM monitors (if active) in all CPUs, using the following operator command:

   F CTMCMEM,STOP

3. If member IOACPRM was corrected, stop and restart the Control‑M monitor.
   • Before restarting the Control‑M monitor, remember to refresh any program fetch product (PDSMAN, PMO, QFETCH, and so on). If the IOA LOAD library was added to the linklist, refresh LLA also.
   • When the Control‑M monitor comes up, it must issue the message CTM440I monitor ready to receive CMEM requests. If this message was not issued, search for error messages within
     • the IOA Log
     • the job log of Control‑M monitor SYSOUT
     • the MVS syslog
   • If no error message is displayed, IOACPARM does not request CMEM processing to be performed. This means that one of the following was not specified:
     • parameter CPUS
     • parameter CTM2SBS in conjunction with parameter Use System Logger set to N (No)
   • If an error message is displayed, it means that Control‑M encountered an error while processing CMEM-related parameters. Locate the problem, correct it and restart the Control‑M monitor.
4. Start CMEM in all CPUs where it must run by issuing the following operator command in each CPU:

   S CTMCMEM

   If CTMCMEM successfully initialized, the following messages appear in the CTMCMEM job log:

   CTM227I IOA subsystem "I600" initialization of Control‑M functions completed.

   CTO147I CTMCMEM - initialization complete. Type=CTMCMEM,SUB=JES2, RUN#=0001

   • If the above messages do not appear in the job log, search for error messages within the CTMCMEM job log and the MVS system log (SYSLOG) in general.
   • While searching, note that all related messages start with a prefix of CTM, CME, or IOA. An error message number usually contains the suffix E (Error) or S (Severe error).
   • Locate the problem, correct it and restart CTMCMEM. If the problem correction includes changes to member IOAPARM, CTMPARM or IOACPARM, return to step 1 above.
5. Submit a test job to evaluate whether CMEM as a whole functions properly. You should perform the basic test described in Step 1 above.
   • The job must be submitted from TSO or ROSCOE in one of the CPUs in which the CMEM monitor is active, and must have the exact name as defined in the CMEM rule table.
   • After message HASP100 (for JES2) or IAT6101/IAT6100 (depending on the JES3 version) is displayed, wait a few seconds and check if the action defined in the CMEM rules table was performed for
     • a request to order a schedule table, check the IOA Log and the Active Environment screen (Screen 3)
     • a request to add or delete a condition, check the IOA Log and the IOA Conditions or Resources Display (Screen 4)
     • The action is actually performed by the Control‑M monitor, so to test the CMEM functions properly the Control‑M monitor must be up.

   Note: IOA Exit 7 and Control‑M Exit 1 receive control before the condition is added or deleted or the table is ordered (respectively). If you use a localized version of these exits, make sure that the exits perform the localized corrections.

   • Repeat this step for all CPUs in which the CMEM monitor is active. If the requested action was not performed by Control‑M, skip to step 8 below.
6. Change the definitions in the CMEM Rule table, or add new events. Define events to test all event types: JOBARRIVAL, JOBEND, DSNEVENT and STEP. For information on changing the CMEM Rule table, see the online facilities chapter of the Control‑M for z/OS User Guide.
7. Issue the operator command F CONTROLM,NEWCONLIST to cause CMEM to reload the updated CMEM Rule tables in all CPUs.

   This command must be issued only in the CPU where the Control‑M monitor is active. It must be issued each time that the CMEM rule tables are modified, and can also be issued to test if the Control‑M monitor and the CMEM monitors communicate with each other.

   The command is directed to the Control‑M monitor. After several seconds, the monitor must issue the message

   CTM101I NEWCONLIST COMMAND ACCEPTED ...

   After several more seconds, the CMEM monitors must issue the message

   CTO240I NEWCONLIST COMMAND RECEIVED. THE CMEM TABLES WERE RELOADED

   • If the CMEM monitor encounters a problem while performing the NEWCONLIST request, an error message is issued to the job log instead of message CME240I.
   • If the CMEM monitor does not issue any message at all, the communication files between the Control‑M monitor and the CMEM monitors or Sysplex Logger were not set up correctly. Locate the error and correct it. If the correction involves changes in IOACPRM or a reformat of the communication files, repeat the test from step 1 above.
8. Submit jobs to test all the event types as defined in step 5 above.
   • These jobs must be submitted from TSO or ROSCOE in one of the CPUs where the CMEM monitor is active. They must run in the same CPU, and must have the exact names as defined in the CMEM Rule table.
   • Check that the actions defined in the CMEM Rule table are performed (the condition was added or deleted, a schedule table was ordered, and so on).
   • Repeat this step in all CPUs where a CMEM monitor is active.
   • After all jobs ended execution, wait a few seconds and check if the action defined in the CMEM rules table has been performed for
     • a request to order a schedule table, check the IOA Log and the Active Environment screen (Screen 3)
     • a request to add or delete a condition, check the IOA Log and the IOA Conditions/Resources screen (Screen 4)
     • a request to stop the job, check the job log of the executed job for messages CTMC41E and CTMC42E
   • If the action for a DSNEVENT or step event is not performed, verify that
     • JOBNAMES monitoring is turned on and message IEF403I is issued in the job log of the tested jobs.

       Note: In product version 9.0.18.100 or later, JOBNAMES monitoring is turned on automatically at CMEM or Control-O startup.

       You can then use the following command to check the monitoring facility status that SETCON sets:

       D OPDATA,MONITOR

     • the MSGLEVEL of the tested jobs is set to (x,1); that is, the JESYSMSG sysout file (the third file listed in the sysout) is created with all the deallocation messages.
     • no error messages appear in the job log of the executed job.
   • If one of these situations cannot be verified, locate the problem, correct it and repeat this step.
   • If these situations can be verified, or if actions for JOBARRIVAL/JOBEND were not performed, continue to the next step.
9. If CMEM does not work properly, and the reason for the error was not located while performing the steps mentioned so far, produce and save the following documentation:
   1. Create a dump of the subsystem communication files (Monitor-to-Subsystem file, and all Subsystem-to-Monitor files). The dump can be created using utility IDCAMS, with the following statements:

      PRINT IFILE(ddname1) DUMP (subsys-to-monitor file)
      PRINT IFILE(ddname2) DUMP (monitor-to-subsys file)

      A sample JCL member can be found in member LISTFILE of the IOA JCL library.

   2. Save the part of the MVS syslog that contains the entire test.
   3. Print the rule table.
   4. Save the IOA log of the entire test. If the IOA log is printed using KSL or Screen 5, use the SHOW command and specify Y in all CM and CO+CMEM options before printing the log.
   5. Print members CTMPARM, IOAPARM and IOACPRM in the IOA PARM library.

   After saving this documentation, contact your BMC Customer Support with an exact description of the problem.