ISGENDOFLQCB — End of Local QCB Exit

ISGENDOFLQCB is called when the last requester for a LOCAL resource (SCOPE=SYSTEM or RNL excluded SCOPE=SYSTEMS, but not SCOPE=STEP) is DEQed. The ISGENDOFLQCB exit is also called for SCOPE=SYSTEMS resources in a GRS=NONE environment. See ENQ/DEQ Exits Installation in z/OS MVS Planning: Global Resource Serialization for the installation flow through ENQ/DEQ exits.

The ISGENDOFLQCB exit point provides the ability to control future calls to this exit point. If the set of ISGENDOFLQCB exit routines indicates that this exit no longer needs to be called for a particular resource QNAME, an entry for that QNAME is added to the GRS Exit Cache. Prior to calling the ISGENDOFLQCB exit point, GRS queries the GRS Exit Cache. If a matching entry is found, and this entry indicates to NOT call the ISGENDOFLQCB exit point, then this exit may be bypassed. To restore processing of a resource through the ISGENDOFLQCB exit, the GRS Exit Cache must be cleared. See, ISGGCECR, ClearCache call in z/OS MVS Programming: Callable Services for High-Level Languages.

The parameter list passed to ISGENDOFLQCB is mapped by ISGYQCBP (QCBP). The parameter list describes a resource for which the last requester on this system has been DEQed.

Note:

This exit is intended for use by OEM serialization products.
If your installation is using an OEM serialization product to replace Global Resource Serialization, you should NOT specify that the exit is to be called last (either with the LAST parameter of the SETPROG command or the POS=LAST parameter of the CSVDYNEX macro) when installing this exit.
After a call to ISGGCECR, the ISGENDOFLQCB exit can be called again for all resources.
If an error occurs in the GRS Exit Cache, the cache is disabled and all resources will again be processed by the ISGENDOFLQCB exit. Re-IPL to restore cache processing.

Replacing the Exit Routine

Unlike RNL changes, GRS does not know how an exit alters the resource identity of a request. Therefore, to maintain data integrity, do not make an exit change that alters the resource identity of any outstanding or in-flight ENQ or DEQ requests. The resource identity consists of the QNAME, RNAME, SCOPE, and hardware reserve status. When you make exit changes, first stop the programs that are currently using the resource, and do not resume the programs until all the exit changes in the GRS complex have completed.

For information regarding dynamic exit routine replacement, see Replacing a Dynamic Exit Routine.

Exit Routine Environment

ISGENDOFLQCB receives control in the following environment:

Task mode.
Enabled for interrupts.
In supervisor state with PSW key 0.
In primary ASC mode.
Might be invoked in the cross-memory mode.
In AMODE 31 and RMODE ANY.
No locks held or local and CMSEQDQ locks held.
An EUT FRR might be held when the exit routine is called.

The routine can be invoked in the cross-memory mode with an EUT FRR established that must remain in effect. Therefore, system services or instructions that do not allow FRRs to be active or cause FRRs to be removed cannot be used. This includes the SVC instruction.

Exit Recovery is as follows.

If an error occurs, the ISGENDOFLQCB exit should provide its own EUT FRR recovery routine.
An EUT FRR recovery is the only recovery type that can be used. ESTAE-like recovery can be established, but it does not receive control because an EUT FRR might be established on entry.
If no recovery exists, or the recovery continues with termination, GRS fails the request and continues processing. CSVDYNEX rules for the exit are used to determine whether the exit should be removed.
The unplanned removal of an exit can result in serialization changes. Therefore, it is important to provide recovery and to understand how CSVDYNEX determines when to remove an abend exit.
For more information about CSVDYNEX, see z/OS MVS Programming: Authorized Assembler Services Reference ALE-DYN.

Exit Routine Processing

The ISGENDOFLQCB exit point is called after the last requester for a local resource (SCOPE=SYSTEM, only) DEQs from that resource. The exit routine is passed a QCBP (mapped by ISGYQCBP) which describes the resource that is being deleted.

Programming Considerations

Observe the following conventions when coding an End of Local QCB exit routine:

Every exit routine must be reentrant.
You should be aware while coding the exit routine, that because the exit is called for every ENQ, RESERVE, and DEQ request, an increased path length increases processor utilization and can degrade performance.
Do not code the exit routine to issue the WAIT macro or call a service, such as WTOR, that issues a WAIT.
Do not code the exit routine to issue another ENQ, RESERVE, or DEQ macro.
Do not code the exit such that the Local or CMSEQDQ locks are freed.

Entry Specifications

The system passes an QCBP parameter list to the exit routine.

Registers at Entry: The contents of the registers on entry to the exit are as follows.

Register: Contents
0: Not applicable
1: Address of the exit parameter list (ISGYQCBP)
2-12: Not applicable
13: Address of a 72-byte save area
14: Return address
15: Entry point address of ISGENDOFLQCB

Parameter List Contents: Register 1 contains the address of the exit parameter (QCBP) that is mapped by macro ISGYQCBP. Refer to z/OS MVS Data Areas in z/OS Internet Library at http://www.ibm.com/systems/z/os/zos/bkserv/ for the mapping of the ISGYQCBP data area.

Return Specifications

The ISGENDOFLQCB installation exit sets the appropriate request flag in the parameter list to indicate if ISGENDOFLQCB exit routine will be called again.

Registers at Exit: Upon return from the exit processing, the register contents must be as follows.

Register: Contents
0-14: Restored to contents on entry
15: 0