Sam Knutson wrote:
>The SFM Policy did not partition the dead systems out of the Sysplex
>without operator intervention. The remaining two systems kept running
>but hung up till operators manually replied.
We have found that there is no right answer for this situation.
Several years ago, APAR OW30926 introduced the support to consider the
existence of signalling traffic as an indicator of "aliveness" of a
system, because I/O delays can prevent a system from updating its
heartbeat status in the sysplex couple data set even though it is in other
respects healthy. However, other installations felt that systems in this
indeterminate degraded condition should indeed be removed from the
sysplex. So the APAR introduced message IXC427A / IXC426D, which prompt
for operator guidance.
To try to eliminate the need for operator intervention in this
situation, APAR OA11591 has been accepted. It is still in the design
phases, while we try to figure out a set of externals that would provide
the right function and not further muddy an already confusing interface.
I'm not clear, though, on why IXC427A would have been issued in the
scenario Sam describes. In a CEC failure, I would not expect to see
signals from the systems residing on the affected CEC. And once the
signals dried up and the affected systems were really and truly in a
status update missing (SUM) condition, I would expect SFM to transition
into its normal processing for isolating those systems in accordance with
Sam's policy. I would have to guess that the configuration remaining
after the CEC failure did not provide the necessary CF connectivity
between the surviving systems and the dead systems. (Isolation requires a
CF with connectivity to both the SUM system and the system that is trying
to effect its removal.)
Bill Neiman
z/OS Development
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html