Member WAITING_FOR_FAILBACK, alert, corresponding host is in ACTIVE state without alert

The output of the db2instance -list command shows that at least one member is in the WAITING_FOR_FAILBACK state with an alert and that one or more corresponding hosts are in the ACTIVE state without alerts.

This is a sample output from the db2instance -list command where there are three members and two cluster caching facilities:
ID      TYPE             STATE                   HOME_HOST               CURRENT_HOST            ALERT   PARTITION_NUMBER        LOGICAL_PORT    NETNAME
--      ----             -----                   ---------               ------------            -----   ----------------        ------------    -------
0       MEMBER           STOPPED                 hostA                   hostA                   NO                     0                   0          -
1       MEMBER           WAITING_FOR_FAILBACK    hostB                   hostC                   YES                    0                   1          -
2       MEMBER           STARTED                 hostC                   hostC                   NO                     0                   0          -
128     CF               CATCHUP                 hostB                   hostB                   NO                     -                   0          -
129     CF               PRIMARY                 hostC                   hostC                   NO                     -                   0          -

HOSTNAME                  STATE                INSTANCE_STOPPED        ALERT
--------                  -----                ----------------        -----
hostC                     ACTIVE               NO                      NO
hostB                     ACTIVE               NO                      NO
hostA                     ACTIVE               NO                      NO
Member 1 experienced a problem with its home host, hostB, and is running in light mode on hostC.
Member 1 shows that an ALERT has occurred. Running db2cluster -cm -list -alert provides information about the alert, as the following output example shows:
Alert: Db2 member '1' is currently awaiting failback to its home host 'coral18'. 
The cluster manager has restarted the Db2 member in restart light mode on another 
host. The home host for the member is available however automatic failback to home 
has been disabled.  

Action: In order to move the member back its home host, the alert must be manually 
cleared with the command: 'db2cluster -cm -clear -alert'. 
Impact: Db2 member '1' will not be able to service requests until this alert has 
been cleared and the Db2 member returns to its home host.

When hostB is available, the state for the host is set to ACTIVE. At this point, the default behavior with the best practice configuration of autofailback is for the restart light member to failback to its home host automatically without any user intervention. However, based on the previous output, the failback did not occur due to the disablement of the autofailback feature. To manually force the failback of the restart light member back to its home host, simply clear the alert on the host.

To restore the best practice configuration with autofailback enabled, issue the following command:
db2cluster -cm -set -option autofailback -value on 
The instance must be restarted for the setting of the previous command to become effective. To verify this, run the following command:
db2cluster -cm -list autofailback