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

The CAS Manager accesses the file and validates the records
If the record is valid, it is dynamically installed.
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.

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*)