Timing Considerations

The time span involved in detecting and responding to a transition of an object you are monitoring introduces several timing considerations, particularly if multiple connections are monitoring the same object. (Note however, that only your connection will be monitoring your event queue.)

If multiple connections are monitoring the same list, the first connection to respond to a list transition could empty the list before other connections test the list notification vector or check the list. Depending on when the other connection emptied the list, either of the following would occur:

Your list transition exit could receive control, test the list notification vector, and find no non-empty lists.
You could test the list notification vector, find the list had become nonempty, then attempt to read a list entry from the list and find the list empty.

Another timing consideration is the possible delay between the time a monitored object changes from empty to nonempty and the time its list notification vector entry is updated. All list transitions for monitored objects are reflected in the list notification vector in the order in which they occur, but the timing of the updates is not guaranteed.

Under certain circumstances, there might be a sizable delay between the time a transition of a monitored object occurs and the time the list transition exit is given control. List transition exits are not given control while a structure is being rebuilt. Once the rebuild processing has finished the list transition exits for the connections that participated in the structure rebuild are given control to inform the connections of any transitions that might have occurred during the rebuild process.

Another circumstance of which you should be aware is that if connectivity to the coupling facility is interrupted, the list transition exit might be given control even though the monitored object has not changed.