Determining When Events Are Skipped

The following explains how a group user routine can determine if XCF skipped notification of the indicated event:

GEMSTATE (member state change)

Compare the current value of GEPLOLDS with the previous value. To do this comparison, the routine had to save the value of GEPLOLDS on a previous invocation. For example, if the last invocation of the group user routine indicated a GEPLOLDS of created, and now its value is quiesced, then XCF must have skipped a GEMSTATE with a GEPLOLDS of active. See The Five Member States, which illustrates the transition of XCF members from one state to another, for help in determining if a state was skipped.

The routine might not be able to determine if XCF skipped some member state transitions. For example, if this is the first invocation of the group user routine and the current value of GEPLOLDS is active, the routine might not be able to determine which GEMSTATE events were skipped. A member can become active from a not-defined, created, quiesced, or failed state. The routine can look at the GEPLHSTY for additional information. (See Parameter List Contents.)

GEUSTATE (user state value change)

Compare the currently presented user state value with the previously presented user state value. However, a difference in the user state values does not necessarily indicate a skipped GEUSTATE event. Another service (such as the IXCQUIES macro), rather than the IXCSETUS macro, might have changed the user state.

The routine might detect a difference in the user state values, and subsequently receive the GEUSTATE notification. For example, a member might change its status-checking interval, and then change its user state value before XCF delivers the notification of the changed interval. When XCF presents the changed interval, the parameter list passed to the group user routine contains the new user state value. So the group user routine could detect the new user state value before XCF presents the GEUSTATE event.

GEMSUMSE (member status update reported missing)

Check the GEPLMISR bit in the parameter list. The GEPLMISR bit is on when a member's status user routine confirms that the member's status update is missing. The GEPLMISR bit is off when a member's status update was never reported missing, or after a member's status user routine confirms that the member's status update resumed. This bit indicates the current monitored state and does not necessarily indicate that the event was skipped.

If XCF presents a GEMNOSUM event without having first presented a GEMSUMSE, the routine can assume that XCF skipped the GEMSUMSE.

The routine might not be able to determine that XCF skipped a GEMSUMSE event, because XCF might skip both the GEMSUMSE and GEMNOSUM events.

GEMSUMDI (member status update assumed missing)

Check the GEPLMISD bit in the parameter list. The GEPLMISD bit is on when XCF assumes that a member's status update is missing. The GEPLMISD bit is off if the member's status update was never assumed missing, or after the member's status user routine confirms that the member's status update resumed. This bit indicates the current monitored state and does not necessarily indicate that the event was skipped.

If XCF presents a GEMNOSUM event without having first presented a GEMSUMDI, the routine can assume that XCF skipped the GEMSUMDI.

The routine might not be able to determine that XCF skipped GNAMMSUMDI event, because XCF might skip both the GEMSUMDI and GEMNOSUM events.

GEMNOSUM (member status update resumed)

Check whether XCF failed to present a GEMNOSUM event after it presented a GEMSUMDI or GEMSUMSE event and one of the following is true:

A GEMSUMSE event occurred and the GEPLMISR bit in the parameter list is off. The GEPLMISR bit is off if the member's status update was never reported missing, or after a member's status user routine confirms that the member's status update resumed.
A GEMSUMDI event occurred and the GEPLMISD bit in the parameter list is off. The GEPLMISD bit is off if the member's status update was never assumed missing, or after the member's status user routine confirms that the member's status update resumed.

The GEPLMISR and GEPLMISD bits indicate the current monitored state. They do not by themselves indicate that an event was skipped.

The routine might not be able to determine that XCF skipped a GEMNOSUM event, because XCF might skip both the GEMSUMSE (or GEMSUMDI) and GEMNOSUM events.

GESYSACT (system reported active)

GESYSACT events are not skipped.

GESYSSUM (system status update missing)

If XCF presents a GESYSSUR event without having presented a GESYSSUM, assume XCF skipped the GESYSSUM.

GESYSSUR (system status update resumed)

If XCF presents two GESYSSUM events without an intervening GESYSSUR, assume the GESYSSUR event was skipped.

GESYSGO (system reported going)

GESYSGON (system reported gone)

GESYSDM (system detected missing)

GESYSDG (system detected gone)

XCF does not skip these events.

GESYSFDI (system failure detection interval changed)

XCF does not skip GESYSFDI events. However, XCF always presents the most current value of the system failure detection interval. Thus, two or more GESYSFDI events might present the same system failure detection interval even though the interval was changed two or more times. This situation is similar to that described under GEUSTATE.

GESUBFDI (member status-checking interval changed)

Compare the current value of GEPLINTV to the previously received value for which the member was active. However, the routine might detect that these two values are different, and subsequently be presented with the GESUBFDI event. This situation is similar to that described under GEUSTATE.

GESYSPRT (system being removed from the sysplex)

XCF does not skip GESYSPRT events.

GEMONREM (member status monitoring removed)

Check the GEPLMONR bit in the parameter list. The GEPLMONR bit is on if XCF removed monitoring for the member. However, this bit indicates that the event occurred and does not necessarily indicate that the event was skipped.