Trigger Error 1195 A node has been missing for 30 minutes after any condition that has a node in a non functional state.

Generally the sequence we have seen is a 1196 warning email that a node has failed and then 30 minutes later an 1195 error indicating that the node has been gone for 30 minutes, which also generates an email, and a call home.

What we have experienced, twice on two different clusters, is a 1196 warning that a node has left the cluster which generates an email. Then we received a 1193 UPS warning that also generates an email. After 30 minutes, we never received the expected 1195 error however and so no call home is ever generated. Unless someone is monitoring their email a failed node can go unnoticed for hours.

We raised this concern a year ago and were told this is working as designed and it happened again recently. This does not seem like the proper SVC response to an node being offline.

Working through our Lab Advocate we received the following response to this request for a design change:
====================================================

When a node goes into service state due to low UPS charge, the warning is generated that this is happened,
at this point the SVC node is just waiting for the UPS to report that it has sufficient charge, and then the node will spring back into life.
UPSs are very bad at knowing how long it will take to get there (or even if they will ever get there).

As such the SVC does not know when it will become available again.
From the cluster's point of view, the node has not left the cluster, it is not offline, and it is fully ready to spring into performing IO once more, after the UPS says it is ready.

If the UPS does decide that the battery is dead - a call home will be triggered, but the UPSs are very bad at doing this.

This is a known issue, and we have fixed it by using our own batteries in the DH8, which behaves as you have asked it to :)
===================================================

Our response is that from the cluster's point of view the node is not offline, but if the other remaining node in the IO group were to then fail, the IO group would go offline. Right? So the node with the UPS issue may as well be offline as it is providing no value in it's state of limbo. The point being that the reason for a call home is to inform IBM that there is something wrong and the risk is raised. When only one node is active, for 30 minutes, the call home should be generated regardless of the reason.

I do appreciate the fact that the DH8 does not have this same exposure, however that does not fix the situation ( design flaw, sorry let's call it what it is :-) ) on the vast majority of the existing SVC population.