Recovering from Change Hub Failure

Running Global Projects

Changing the Hub : Recovering from Change Hub Failure

Very rarely, the project may be in a state where a Hub change has been carried out but has failed. In this situation, the user may effectively have no Hub.

During a Hub change, or when a Hub change has failed, the identities of the old and new hubs are recorded on the Location World /*GL. Navigate to the location world and query Hubrf, Prvrf and Nxthb attributes:

/*GL
q hubrf

q prvrf

q nxthb

When there is no Hub, then Prvrf records the name of the previous hub and Nxthb records the name of the next hub. The Hubrf attribute is set to Nulref. During a Hub change from London to Tokyo, Prvrf would be /London and Nxthb would be /Tokyo.

Normally, when a Hub change fails, the previous Hub will be restored automatically as part of the failure operations of the Hub change. The user should check progress of the command in the transaction database. If this recovery fails, then the System Administrator must recover the previous Hub as described below. This will be necessary in the following circumstances:

•

If the daemon is down

•

For offline locations

In all other circumstances it is better await the completion of the in-built recovery operation, since this prevents incompatible changes being made by two competing users at different locations.

To force recovery from a failed Hub change, at the original Hub, use the Data>Recover>Hub Location option from the ADMIN menu bar, or type the following command:

PREVOWNER HUB

Re-enter the ADMIN module. This will restore the Hub location and the Hub GUI. (Note: if daemons are running, then the original Hub location command may still be in progress and will attempt to commit the hub change or recover the original hub as appropriate)

Make sure that the PREVOWNER command is complete before working with either the new or old Hub, as otherwise it is possible to end up with two Hubs. If this happens, the Global database must be propagated (or physically copied) from the new Hub to the old before further administration is be carried out. If the new Hub was to merge changes while the old Hub was still active, the system would not be able to recover. It would be necessary to reinstate the Global database from the backup taken before the change of Hub location was undertaken.