Some further clarification:
To partition a system from the sysplex, XCF must isolate or "fence" the
target system from the channel subsystem, in order to ensure that it is no
longer capable of initiating I/O and thus can no longer affect resources (CF
structures, data bases, etc.) shared by other members of the sysplex. XCF
issues IXC102A whenever it cannot automatically isolate the target system
from the channel subsystem.
When removing a system because it is "status update missing" (that is,
the system has failed to update its heartbeat information in the sysplex couple
data set for a period greater than the failure detection interval), XCF's
processing is governed by the contents of the SFM policy. If SFM is in use on
all systems in the sysplex and there is an active SFM policy and it specifies
ISOLATETIME, DEACTTIME, or RESETTIME (i.e., anything other than PROMPT)
for the affected system, XCF will attempt to take the specified automatic
action. In the case of ISOLATETIME, there must be a CF that is connected to
both the affected system and some other system in the sysplex from which
isolation can be initiated. If the requirements are met and isolation
succeeds,
you will not see IXC102A. If isolation cannot be initiated or fails for any
reason, XCF will issue IXC102A to prompt for manual system reset.
When removing a system in response to a VARY XCF,sysname,OFFLINE
command, XCF will attempt automatic isolation of the outgoing system as long
as there is an active SFM policy, regardless of what it specifies for the
target
system. If there is no SFM policy, or if isolation fails for any reason (no
connected CF, or whatever), XCF issues IXC102A.
If XCF issues IXC102A, it is an absolute, sure-enough, hey-no-kidding
requirement that you reset the target system BEFORE replying DOWN to the
message. The moment you reply DOWN, XCF will mark the target system
inactive and the remaining systems in the plex will begin reclaiming its
resources. If that system has not in fact been reset, and is still trying to
access shared resources for which it no longer holds serialization, merry hell
will break loose in the form of data base corruption or any other scenario you
can conceive that can begin from a state where two entities are
simultaneously manipulating the same critical resource.
Bill Neiman
XCF Development
On Mon, 28 Apr 2008 07:37:56 +0200, Barbara Nitz <[EMAIL PROTECTED]>
wrote:
>>I'm looking to get clarification on whether or not the z/OS console
>>IXC102A message requesting that the operator confirms that a member of a
>>sysplex bas been reset always appears when a member is removed from the
>>sysplex.
>
>No. In order for it NOT to appear,
>
>1. You must have a parallel sysplex with at least one CF.
>2. You must have an SFM policy active.
>
>Then all but the last system can be system-reset automagically through the
CF (initiated by SFM, and you don't see it). The last system in the sysplex has
to be system-reset manually, as there is no one else around in the sysplex to
do it. But then you wouldn't see that message, either.
>
>As the message states, you may see IXC102A when both 1 and 2 above are
fulfilled. The only time I ever saw it I followed up on it and it turned out
that
there was a bug somewhere in coexistence code between releases, and I
should not have seen the message at all.
>
>>I have been told that some installations never see it, and I suspect it
>>it would not be replied to by automation without somehow managing to
>>cause a system reset to occur on the member being removed.
>
>Well, if you reply to it via automation and that automation is not capable of
actually system-resetting the lpar before replying, then you may be in deep
do-do, and it's all your fault. :-)
>
>Regards, Barbara Nitz
>--
----------------------------------------------------------------------
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
