IXC102A — XCF is waiting for system deactivation

XCF is removing a system from the sysplex and needs the operator to confirm that the system has been reset. Replying DOWN too early risks data damage.

What happened

A sysplex member stopped responding or was varied out. XCF started partitioning it out and issued a WTOR on the remaining systems, asking the operator to reply when the failed system has been reset.

Console on a surviving system (illustrative)Illustrative example

IXC101I SYSPLEX PARTITIONING IN PROGRESS FOR MPSYS2 REQUESTED BY
        XCFAS. REASON: SYSTEM STATUS UPDATE MISSING
*025 IXC102A XCF IS WAITING FOR SYSTEM MPSYS2 DEACTIVATION. REPLY DOWN
        WHEN MVS ON MPSYS2 HAS BEEN SYSTEM RESET.
R 25,DOWN
IXC105I SYSPLEX PARTITIONING HAS COMPLETED FOR MPSYS2 ...

What it means

Before the other systems can take over shared resources, the departing image must be unable to do any more I/O to shared devices. XCF cannot prove that on its own, so it waits for the operator. The system is not removed until the operator has reset it and replied DOWN.

IBM lists the hardware actions that satisfy the requirement: SYSTEM RESET (normal or clear), LOAD, IML, power-on reset, removing power, or deactivating/resetting the LPAR. A disabled wait state on its own is not enough. If a stand-alone dump is wanted, use a normal (not clear) reset so storage is kept.

Typical causes

A system failed or hung and stopped updating its status in the couple data set.
An operator issued V XCF,sysname,OFFLINE to remove a system.
No sysplex failure management (SFM) policy, or one that cannot isolate the system automatically, so a manual reply is needed.

Symptoms

IXC101I followed by an outstanding IXC102A reply on the remaining systems.
Work that needs resources held by the failed system waits until partitioning completes.
IXC105I appears once partitioning has finished.

Where to look

The console or OPERLOG for IXC101I (reason) and IXC102A.
The HMC for the state of the departing LPAR.
D XCF,SYSPLEX to see member status.

How to diagnose

Read the reason in IXC101I: operator request, status update missing, connectivity loss, and so on.
Confirm on the HMC which LPAR is the departing system — check the name, not the position on the screen.
Decide with the systems programmer whether a stand-alone dump is needed.
Reset the LPAR (normal reset if dumping), then reply DOWN.

How to fix

Reset the named system from the HMC, confirm the reset, then reply R nn,DOWN to IXC102A. After IXC105I, investigate why the system failed and re-IPL it when ready. Where IXC102A appears often, ask the systems programmers to review the SFM policy so isolation can happen automatically.

How to prevent

Have an SFM policy that suits the site, so a failed system is isolated without a manual reply where hardware allows.
Keep an IXC102A runbook with HMC screenshots and LPAR names.
Use the documented shutdown procedure (V XCF,sysname,OFFLINE and its confirmation) for planned removals.

Production considerations

Interview question

Why does XCF wait for a reply to IXC102A instead of just removing the system?