An authorized caller of the ENQ services needs to protect itself from an unauthorized caller blocking or releasing the resource prematurely. Although an unauthorized caller cannot specify a task other than its own, an authorized caller could still be vulnerable if an unauthorized caller can acquire ENQs under the same task

GRS users define the QNAME/RNAME of resources. As such, the user defines the usage and meaning. See the ENQ/DEQ Summary table in z/OS MVS Diagnosis: Reference for definitions of the used ENQ resources (QNAME/RNAME). It is helpful to know the usage when observing ENQ/RESERVE activity and contention.

You can set the AUTHQLVL parameter in the GRSCNFxx parmlib member to indicate whether the system is to recognize the second list of authorized qnames in addition to the original list. For information, see z/OS MVS Initialization and Tuning Reference.

An option on the DISPLAY GRS system command allows you to display the value, and an option on the SETGRS system command allows you to fall back to the original IBM® default list of authorized qnames if you have enabled your system to recognize both lists. For information, see z/OS MVS System Commands.

Also, the Health Checker for z/OS health check GRS_AUTHQLVL_SETTING exists to help you determine the need of authorized qname protection for your installation. See z/OS Migration.

Authorized programs that are currently using unauthorized qnames in their ENQ requests should consider changing the qnames to authorized usage. This change is not trivial especially if the resources might be global. Also, other products that might interact with the qname resource can also have an impact on any changes that you make. The following protocol for transitioning an ENQ resource to use an authorized qname can help with planning such changes:

1. Add an ENQ resource with an authorized qname and the same rname and scope as the unauthorized ENQ. The following conditions apply:
   • The ENQ resource needs to be used wherever the unauthorized resource is used.
   • The ENQ resource needs to be in a list request to ensure that global resource serialization processes the set atomically.
   Performing a rolling IPL should be sufficient for global requests.
2. Communicate the intention to transition from one qname to another. Consider the following factors:
   • Synchronize the possible RNL definitions in the global resource serialization complex.
   • Be sure to update any separate product that interacts with the ENQ resource. Consider a waiting period of two years. If no other product interacts with this resource, this waiting period might not be necessary.
   • A
3. Before you make the change to remove the unauthorized ENQ resource and leave the new authorized ENQ resource in place, you must require that all systems are using both ENQ resources. The EQDQ Monitor can filter on qname to help diagnose usage. Performing a rolling IPL should be sufficient for global requests.

To avoid any possible integrity problems, ISGENQ checks that an authorized caller uses an authorized qname. For COND=YES, a return and reason code of 040D is returned. For COND=NO, ABEND338 is issued for an OBTAIN or CHANGE request or ABEND330 is issued for a RELEASE request.

For more information, see the ISGENQ description of ISGENQRsn_UnprotectedQName and ISGENQRsn_UnprotectedExitQName in z/OS MVS Programming: Authorized Assembler Services Reference EDT-IXG.