Excluding requests from RNL processing

Guideline: Use the default RNL=YES.

An ENQ or DEQ request can be excluded from RNL processing by specifying RNL=NO on the request. When RNL=NO is specified the ENQ request will be ignored by alternative serialization products, and this will impact protection of the resource to systems outside of the current global resource serialization environment using alternative serialization products. Use RNL=NO only after understanding and considering the impacts of its specification to the control of the resource by an installation-specified RNL.

Rules: Consistent usage of the RNL= and resource scope specifications is important:

If RNL=NO is specified for a resource on the ENQ request, it must also be specified on the DEQ request.
Do not mix ENQ RNL=NO and RNL=YES requests that use the same Qname and Rname.
Do not mix ENQ scope SYSTEM and SYSTEMS requests that use the same Qname and Rname.

Not following these rules can result in abends, incorrectly obtaining serialization, failure to obtain serialization, or failure to release serialization.

When to Use RNL=NO:

Use RNL=NO for scope SYSTEMS requests where the application is communicating exclusively within a sysplex (as with XCF and XES services) and would never be viable for a scope outside that sysplex. Because only systems within the sysplex are fully aware of the state of the resource, it is appropriate to specify RNL=NO to avoid having the request incorrectly altered by the GRS or alternate serialization product RNL processing. Note that GRS installation exits can also request that RNLs not be processed.