CONNECT DIRECT Support (Formerly NDM Support)

Control‑M supports CONNECT DIRECT software, which creates dataset events (that is, the appearance of a dataset) on the system. CONNECT DIRECT support enables dataset events to automatically trigger Control‑M operations (adding and deleting prerequisite conditions, and/or triggering jobs) to handle these events.

The Control‑M user creates and modifies dataset event definitions by using online Event Definition and Event List screens.

CONNECT DIRECT support consists of the following phases:

• Implementation and Customization
  1. Create a Rules library with the following attributes:

     LRECL=132,BLKSIZE=13200,DSORG=PO,RECFM=FB

  2. Add the @@IDCNTL member to the Control‑M PARM library. This member must contain a single line (in the format shown in the table below) for each user who is going to use this facility.

  Table 113 Format of Line in the @@IDCNTL Member

  Columns	Description
  01–08	User ID
  09–52	Name of the Rules library
  53–60	Member name (user ID recommended)

  Note: When a table or an event list table was in use during the execution of an IOADDC request, and no successfully triggered event was processed, Control‑M may try again to execute the request, depending on the values set for the FORCE#RT and FORCE#WI installation parameters. For more information on the FORCE#RT and FORCE#WI installation parameters, see the customization chapter of the INCONTROL for z/OS Installation Guide: Customizing.

  When wish WM3683 is set to APPLY=YES (see member IOADFLT in the IOA IOAENV library) then all IOADDC/IOADDR Requests will verify that the requestor's USERID (ACEEUSER from the job's USER= JOB statement or the user who submitted the job) matches the USERID specified in col 1-8 of each @@IDCNTL record before checking the associated rule library/member for the corresponding dataset.

  If the wish is set to NO, then the userid is not verified and the first rule library/member in which the dataset appears is used.

  The setting of WM3683 does not affect IOA basic or extended security considerations but is simply used to determine which @@IDCNTL record (rule library) is to be used.

Example

The following sample CONNECT DIRECT script calls the IOADDR dataset driver to set a different prerequisite condition upon successful or unsuccessful completion of a file transfer:

IOADDSTR PROCESS PNODE=PRIMNODE

                 SNODE=SECDNODE

STEP01 COPY FROM (PNODE DSN=INDSN DISP=SHR) -

              TO (SNODE DSN=OUTDSN DISP=SHR)

STEP02 IF (STEP01 = 0) THEN

          RUN TASK (PGM=IOADDR, -

                    PARM=('OUTDSN.COPY.GOOD')) SNODE

       ELSE

          RUN TASK (PGM=IOADDR, -

                    PARM=('OUTDSN.COPY.FAILED')) SNODE

       EIF

• Dataset Event Definition (REXX Procedure IOACDDR)

  Dataset event definitions are created and modified by the Control-M user using online Event Definition and Event List screens. The user must define at least one Event list. An Event list is composed of dataset names and, for each dataset name, the operations that the dataset event must trigger. Event lists are defined or modified in the Dataset Event Definition facility that is activated using the IOACDDR REXX procedure. For more information, see “REXX Procedure IOACDDR: Dataset Event Definition.

• Automatic Operation Triggering Upon Dataset Appearance (Module IOADDR)

  Once Event lists are defined, they can be used to trigger operations that are based on dataset events. The main module involved is module IOADDR.

  Whenever a dataset event occurs, the IOADDR module must be invoked, and the name of the dataset must be passed to it as a standard parameter. The IOADDR module looks for the passed dataset name in the Event lists. If it finds the dataset name in a list, it initiates the corresponding action.

  The IOADDR module can be called from any calling environment (job, TSO, CONNECT DIRECT, and so on). Before the module can be called, certain files must be allocated to the module.

  In most cases, the calling environment allocates the required files and calls the IOADDR module directly.

  If the calling environment cannot allocate the files, it cannot directly call the IOADDR module. Instead, replace calls to IOADDR with calls to the IOADDC module. In this case, the process is as follows:

  The calling environment calls the IOADDC module and passes the dataset name as an argument. The IOADDC module places the dataset name in a System Logger log block that is read by Control-M.

  If the IOADDC module cannot build the System Logger environment or write a System Logger log block (for example, the address space running IOADDC is not authorized), the module issues error messages to help the user troubleshoot the problem.

  Control-M calls the IOADDR module and passes the dataset name as an argument. The IOADDR module checks the Dataset or Event table and triggers the corresponding event. For information on setting up the System Logger, see “CMEM—Control-M Communication” and the Control-M chapter in the INCONTROL for z/OS Installation Guide:Installing.

  If the IOADDC module is executed and the System Logger interface was not enabled by the user (parameter SYSTLOGR in the IOACPRM IOA PARM member is set to 'N'), then instead of passing the dataset name argument to Control-M using the System Logger, IOADDC directly calls IOADDR to trigger the corresponding event.

  To enable a single CONNECT DIRECT-caller to communicate with multiple IOA installations simultaneously, see CONNECT DIRECT Cross Installation Support.

EXEC IOADDC,PARM=(’dataset-name’)

Note: The environment that calls the IOADDR/IOADDC module must have the DAPARM DD statement allocated to it. For further information see Customizing the IOA Online Environment.