• 1 reply
  • Latest Post - ‏2012-07-25T18:45:42Z by BryanChilds
1 Post

Pinned topic z/OS latch problem

‏2012-07-12T14:16:45Z |
We are introducing latches into an application on z/OS 1.13 and have encountered behavior that does not match our interpretation of the documentation.

In the OSMVS Programming: Authorized Assembler Services Guide the description of the latch purge service states that latch purge “purges all granted and pending requests”. From this our understanding is that latch purge acts as a general latch release and we expect that if we have a set of waiters for a latch and purge the latch set that the waiters would have their latches released and resume execution.

If we have a set of processes with a latch owner and a set of waiters and we iterate over the set and issue ISGLREL for each process as it gains ownership the processes will resume execution.

However when we issue latch purge it completes rc 0 and the D GRS,LATCH display shows no latch contention but the RBs for the latch waiters remain paused and the processes do not resume execution. This occurs for both ISGLPRG and ISGLBPA.

At this point we are not sure if the latch purge behavior is a defect or if the actual behavior is different from our interpretation of the documentation.
Updated on 2012-07-25T18:45:42Z at 2012-07-25T18:45:42Z by BryanChilds
  • BryanChilds
    1 Post

    Re: z/OS latch problem

    This question was posted and answered on IBM-MAIN. Here's a copy of the answer:

    Latch Purge processing does not resume suspended work units of the purged requesters. There is no return code on Latch Obtain for example that would indicate that control was returned yet the request was purged. Latch Purge processing may result in OTHER requesters getting resumed if a purged request was an owner but that is certainly a different case. The documented purpose of Latch Purge processing is to purge granted and pending latch requests when multiple errors prevent Latch Release from being used.

    Bryan Childs
    GRS Development