Steve, I appreciate your comments, but lets get back to the question I
raised. For the purposes of this discussion, please assume that I am fairly
knowledgeable about HADR, having worked with it for several months now, so
lets dispense the fundamentals.

If the original primary server crashes (assume a hardware failure of some
kind), we will do an HADR takeover by force (force is necessary because the
original primary is unreachable) and original standby is now the primary.
Obviously databases are no longer in peer state if the original primary
server crashes because of hardware failure. Once the takeover has occurred,
DB2 automatic client reroute (or whatever mechanism one chooses) will point
the applications to the new primary server (which was previously the standby
database). Processing of the application continues normally.

Now, at some subsequent point, we will fix the hardware problem with the
original primary and attempt to bring it online as the standby. After it is
brought online as the standby, it will catch up with the logs, and only then
we can do a HADR takeover (without force) to make it the primary again. I
don't think the timeout is relevant since I am assuming that original
primary will be down for several hours before it can be repaired.

However, the problem is how do I bring the original primary server back up
after hardware repair as the standby. In its last state before the server
crashed, it thought it was the primary, and since a HADR takeover has now
occurred and the original standby is now the primary, then I will have 2
primary databases (split brain) when the original standby is repaired and
brought back up. Any new connections might go to the original primary before
I have a chance to make it the standby by issuing the command:
db2 "start hadr on database <original_primary_database> as STANDBY"

So how do I prevent a split brain (even for a short period) when my primary
server crashes and I bring it back online, and before I can designate it as
the standby (I already have a primary running). This seems like a
fundamental issue that must be solved for HADR to provide a continuous
availability solution.

One of the things that I think DB2 should do, is that any database where
HADR is configured should attempt establish peer state before any
connections are allowed, and if the other database is already in primary
role, and it was activated first, the last database to be activated should
either automatically start as standby, or should not allow connections until
some affirmative action is taken by the DBA (allowing the DBA to designate
it as standby before any connections are allowed).

In the absence of DB2 providing the above capability, perhaps there are some
procedural things that can be done to not allow connections when the server
is brought back up, allowing the DBA to make it standby. But I don't see how
this can be done via SQL statements (such as revoke connection authority)
since the revoke can only be issued on a database that is primary and
available for new connections.