Preparation for Changing the Hub

Changing the Hub is a straightforward process, but any break in communication links could potentially complicate matters. AVEVA Global can handle and recover from communication failure, but AVEVA recommend the following preliminary steps are taken to minimize the risk of Hub change failure:

• Make sure that the daemon is running at both the current Hub and the Satellite which will become the new hub. This can be done by selecting Query > Global States > Communications from the ADMIN, DRAW, MODEL or SPOOL module or by issuing a Ping command.

• Make sure that the project at the Hub is backed up and that at least the Global database (i.e. prjglb) at the satellites is backed up.

  Once these steps have been taken, the user can change the Hub through the command line. The GUI will automatically change at the old Hub. At the new Hub, re-enter ADMIN.

  Output to the Global daemon window will indicate that the location is now the Hub or Satellite.

• Note that all databases, including non-propagating databases must be allocated to the proposed new Hub, for example /Tokyo, before changing the Hub. This may be done using the command:

  Allocate all at /Tokyo override propg

• or by checking the option ‘Allocate all’ to allocate non-propagating databases on the Database Allocation (by location) form.

Make sure that the change of Hub location is complete before working with either the new or old Hub. Check the following attribute to confirm that the hub change has been successful. For example, if the user is changing the Hub from London to Tokyo, then navigate to the location world /*GL and query the Hubrf attribute:

/*GL

q hubrf

The Hubrf should be set to the name of the new Hub location; in this example, /Tokyo.

See that the location parent attribute of each location (locrf) has changed. This is a secondary effect, because the Hub location can have no parent. In the above example, navigate to the location of the old Hub and query the Locrf attribute:

/London

q locrf

The Locrf should be set to the name of the new Hub location; in this example, /Tokyo. (Previously, London, as the old Hub, had no parent location.)

Now, navigate to the location of the new Hub and query its Locrf; for example:

/Tokyo

q locrf

If the Locrf of Tokyo is set to Nulref, then the hub change has been successful. The new hub, Tokyo, has no parent location.