Resource locking considerations with block level sharing
Resource locking can occur either locally in a non-sysplex environment or globally in a sysplex environment.
In a non-sysplex environment, local locks can be granted in one of three ways:
- Immediately because of one of the following reasons:
- IMS was able to get the required IRLM locks, and there is no other interest on this resource.
- The request is compatible with other holders or waiters.
- Asynchronously because the request could not get the required
IRLM latches and was suspended. (This can also occur in a sysplex
environment.) The lock is granted when latches become available and
one of three conditions exist:
- No other holders exist.
- The request is compatible with other holders or waiters.
- The request is not compatible with the holders or waiters and was granted after their interest was released. (This could also occur in a sysplex environment.)
In a sysplex environment, global locks can be granted in one of three ways:
- Locally by the IRLM because of one of the following reasons:
- There is no other interest for this resource.
- This IRLM has the only interest, this request is compatible with the holders or waiters on this system, and XES already knows about the resource.
- Synchronously on the XES CALL because of one of the following
reasons:
- XES shows no other interest for this resource.
- XES shows only SHARE interest for the hash class.
- Asynchronously on the XES CALL because of one of three
conditions:
- Either XES shows EXCLUSIVE interest on the hash class by an IRLM, but the resource names do not match (FALSE CONTENTION by RMF).
- Or XES shows EXCLUSIVE interest on the hash class by an IRLM and the resource names match, but the IRLM CONTENTION EXIT grants it anyway because the STATES are compatible (IRLM FALSE CONTENTION).
- Or the request is incompatible with the other HOLDERs and is granted by the CONTENTION Exit after their interest is released (IRLM REAL CONTENTION).