RNL Support

RNLs are an IBM mainframe method used by GRS to identify resource scope. Of the RNLs functions, only those essential for identification of a SYSZDSN lock scope have been implemented.

Enterprise Server RNLs Implementation Limitations

There is no support for:
  • RNL=NO
  • GRSRNL=EXCLUDE
  • GRS=NONE
  • The ISGNQXIT or ISGNQXITFAST exit

RNLs are always used.

Enterprise Server RNLs Configuration

ESCLRNLs.cfg file characteristics
  • All RNLs must be created in a single file called ESCLRNLs.cfg.
  • This file must be located in the same folder as the CATALOG folder shared by all members of the Enterprise Server Cluster.
  • The name and location are not configurable.
  • The file ESCLRNLs.cfg is a line sequential file.
  • The file contains all the RNLDEFs to be loaded in each member of the Enterprise Server Cluster.
ESCLRNLs.cfg file processing
  1. The CAS Manager accesses the file and validates the records
  2. If the record is valid, it is dynamically installed.
  3. At the end of RNLs file processing, the following message is sent to the console:
    TXSI9024I nnn RNLDEF loaded from ESCLRNLs.cfg
    where nnn is the number of RNLs successfully loaded from the file.
If the Enterprise Server Cluster manager does not find an ESCLRNLs.cfg file, it creates a default one and adds a single line to it:
RNLDEF RNL(INCL)TYPE(GENERIC) QNAME(SYSZDSN) 
This will result in the scope set to global(servers) for ALL SYSZDSN.

The file is accessed by the Enterprise Server Cluster manager only. All cluster clients will request the RNLs during the Enterprise Server Cluster client region startup. This processing is part of the handshaking executed by transaction fafaffff from the pltpi in the Enterprise Server Cluster client regions.

When RNLs have been received from the GLM, the client will send the following message to the console:
CASSI9025I All RNLDEFs received and installed from ES Cluster Manager GML_NAME

Enterprise Server RNLDEF Support Limitations

For Enterprise Server Clusters, the RNLDEFs are defined using:
An RNL identifier
  • RNL(EXCL) for the SYSTEM exclusion list
  • RNL(INCL) for the SYSTEM inclusion list
An entry type indicator
  • TYPE(SPECIFIC) - the entry is a specific name
  • TYPE(GENERIC) - the entry is a generic name
  • TYPE(PATTERN) - the entry is a pattern name
A qname
  • QNAME(QUEUE_NAME)

    Enterprise Server Clusters only process three queue names: SYSZJOBD, SYSZJOBN and SYSZDSN. RNLs are only used to define the scope of the SYSZDNS resources. SYSZJOBD and SYSZJOBN are always global (scope = servers).

An rname
  • RNAME(Resource_name)

    As the only QNAME used for RNLs is a SYSZDSN, the resource name maximum length is 44.

Enterprise Server RNLDEF Format

The mainframe allows a much looser format than the Enterprise Server Cluster implementation. See: http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.ieae200%2Fiea2e2b0169.htm

In an Enterprise Server Cluster, a restricted format applies:
  • No restrictions on columns, but an RNLDEF must be contained in a single line.
  • No support for comments.
  • Each RNLDEF statement is defined as beginning with the characters RNLDEF and ends at the end of the line.
  • Each RNLDEF statement must contain, in any order, the RNL, TYPE, QNAME and RNAME parameters. The only exception to this is:
    • The RNAME parameter may be omitted it TYPE(GENERIC) is specified for a generic QNAME resource. For example:
      RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(SYSZDSN) 
      This will result in the scope set to local for all SYSZDSN.
  • You can put a blank anywhere except within a keyword or a specified value.
  • There is no verification on the RNAME.
  • Formats such as RNAME(X'19') are not supported.
  • A specific resource name entry matches a search argument only when they are exactly the same. A match occurs only when the length of the RNAME value on the RNLDEF statement is the same as the length of the RNAME value coded.

RNLs Processing

The IBM diagram below illustrates RNLs processing. An Enterprise Server Cluster emulates this behavior, but note that the Enterprise Server JES subsystem never sets the scope to SERVERS (equivalent to IBM SYSPLEX or SYSTEMS value), and therefore the INCLUDE list is systematically processed. If an INCLUDE RNL matches the RNAME, the EXCLUDE list is searched.
IBM RNLs processing flowchart as emulated by an Enterprise Server cluster

Note that the RNLDEF processing will stop on the first match for both INCLUDES and EXCLUDES.

RNLs Examples

List of INCL/EXCL:

RNLDEF RNL(INCL) TYPE(SPECIFIC) QNAME(SYSZDSN) RNAME(SYS.CLUSTER.MYFILE)

RNLDEF RNL(INCL) TYPE(SPECIFIC) QNAME(SYSZDSN) RNAME(SYS1.CLUSTER.SPEC001)

RNLDEF RNL(INCL) TYPE(SPECIFIC) QNAME(SYSZDSN) RNAME(SYS1.CLUSTER.SPEC002)

RNLDEF RNL(INCL) TYPE(SPECIFIC) QNAME(SYSZDSN) RNAME(SYS1.CLUSTER.SPECXXX)

RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSZDSN) RNAME(SYS1.CLUSTER.SPECXXX)

RNLDEF RNL(INCL) TYPE(GENERIC) QNAME(SYSZDSN) RNAME(SYS1.CLUSTER.GEN)

RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(SYSZDSN) RNAME(SYS1.CLUSTER.GENEXXX)

RNLDEF RNL(INCL) TYPE(PATTERN) QNAME(SYSZDSN) RNAME(SYS1.CLUSTER.PATT???)

RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(SYSZDSN) RNAME(SYS1.CLUSTER.PATTX)

RNLDEF RNL(EXCL) TYPE(PATTERN) QNAME(SYSZDSN) RNAME(SYS1.*.PAT*X2)

RNLDEF RNL(INCL) TYPE(PATTERN) QNAME(SYSZDSN) RNAME(SYS1.H???A.O*)