|
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.
|