There is a need for a new GLUE point in the DISABLE LIBRARY processing

When a user issues a DISABLE LIBRARY command to CICS (either directly, or indirectly via a DISABLE BUNDLE) then one of CICS' obligations is to de-allocate the library. While Xpediter maintains an open handle against the DCB there is no possible way for CICS to honour it's obligations and complete the user request so clearly there is a design issue here between the two products. The unfortunate thing from the CICS perspective is that CICS has no way to know that a disable will not complete until we get mid way through the attempt. So we have no way of blocking the attempt to DISABLE the library, and currently have no way to recover from the failure.
.
I understand not wanting to hook XEIIN, but I do think that the solution
to this requires a mechanism by which Xpediter can close the open handle before CICS attempts to de-allocate the library. What I'm thinking is that there is a need for a new GLUE point in the DISABLE LIBRARY processing. This would need to be in the LD layer not the exec layer to pick up requests caused by a DISABLE BUNDLE request. This would enable non-CICS code with an interest in Libraries to listen out for state changes against those Libraries, and perform their own clean up as required in advance of CICS attempting to perform the state change. In this way, we would avoid the problematic "BEING DISABLED" state from occurring.
Another option I am thinking of is to intercept the DISABLE BUNDLE
request (i.e. before the bundle is disabled) so that Xpediter can go
through all the libraries within the bundle and bypass the DISABLE
request if any of the libraries is open, and issue a message to inform
the user.

Just thought this may be an easier solution. Please let CICS
developers consider this as well.