Setting up IRLM procedures

For each IRLM component that can be activated, you need a procedure that is invoked when the system console operator enters the z/OS® START command.

An example of one such procedure is DXRJPROC, described in IMS Version 15.4 System Definition. If you plan to use more than one IRLM procedure on a single operating system, include additional members in IMS.PROCLIB or SYS1.PROCLIB. Additional IRLMs require a unique identifier and any desired changes in parameter values. The procedure name cannot be the same as the IRLM subsystem names established for z/OS.

For each IRLM component, the procedure parameters specify:

The PARM1= and PARM2= positional parameters for the region that executes in support of block-level sharing are shown in the following table.

Table 1. Categories and purpose of IRLM region parameters
Category Parameter (PARM1 and PARM2) Purpose
Component name IRLMID An identifier for this IRLM.
IRLMNM z/OS subsystem name.
Scope of control SCOPE Inter-z/OS communication or intra-z/OS control.
Data sharing IRLMGRP Name of the z/OS cross-system coupling facility group.
MAXUSRS Maximum number of users in the group.
LOCKTAB Lock structure to be used by the group.
Storage MAXCSA Maximum amount of z/OS common service area (CSA) to be used. This parameter does not apply to IRLM 2.2 and above.
PC Specifies control blocks in private storage. IRLM 2.2 always runs with PC=YES.
PGPROT Determines whether the IRLM load modules that are resident in common storage are placed in MVS PAGE PROTECTED STORAGE, default is YES.
Performance DEADLOK Deadlock detection timing.
Tracing TRACE Trace types DBM, XCF, and SLM turned on at IRLM initialization (EXP, INT, and XIT are always on).

Identifying IRLM

The IRLMID parameter specifies a decimal number (from 1 to 255) for IRLM identification. The IRLMID gets converted to a hexadecimal equivalent. A unique number must be assigned for each IRLM. IRLM error and status messages include the subsystem name and ID of the IRLM that issued the message.

The IRLMNM parameter specifies the 1- to 4-byte z/OS subsystem name that is to be assigned to this IRLM. Unless more than one IRLM is used at the same time on the same system, you can use IRLM as the subsystem name in each operating system. When IRLMs are used concurrently on a system, the subsystem names must be unique.

Specifying IRLM scope

You must specify what kind of data-sharing control is required of the IRLM component–whether sysplex or nonsysplex sharing is to be used. The SCOPE parameter accomplishes this. SCOPE=GLOBAL specifies sysplex data sharing is to be controlled. This is sharing of resources among multiple systems.

SCOPE=LOCAL limits data sharing to nonsysplex data sharing. This is sharing of resources among IMS systems all identified to a single IRLM. If a coupling facility is not available, SCOPE=LOCAL is required. SCOPE=NODISCON specifies sysplex data sharing is to be controlled with special DISCONNECT rules. SCOPE=GLOBAL or NODISCON requires that a coupling facility be defined.

IRLM deadlock management

IRLM provides deadlock management. Using the DEADLOK parameter in the DXRJPROC procedure, you can specify the local deadlock-detection interval and the number of local cycles that are to occur before IRLM initiates a global deadlock detection. You can specify the local deadlock-detection interval in seconds or milliseconds. You can also dynamically modify the DEADLOK values using the z/OS command MODIFY IRLMPROC.

In a data-sharing environment, the participating IRLMs synchronize their DEADLOK parameters to the highest values provided. You should make this parameter the same for each IRLM in the data-sharing group.

Related readings:

  • For more information about the DXRJPROC procedure and the DEADLOK parameter, see IMS Version 15.4 System Definition.
  • For more information about the command MODIFY IRLMPROC, see IMS Version 15.4 Commands, Volume 3: IMS Component and z/OS Commands.