Академический Документы
Профессиональный Документы
Культура Документы
User Guide
AVEVA Solutions Ltd
Disclaimer
Information of a technical nature, and particulars of the product and its use, is given by AVEVA
Solutions Ltd and its subsidiaries without warranty. AVEVA Solutions Ltd and its subsidiaries disclaim
any and all warranties and conditions, expressed or implied, to the fullest extent permitted by law.
Neither the author nor AVEVA Solutions Ltd, or any of its subsidiaries, shall be liable to any person or
entity for any actions, claims, loss or damage arising from the use or possession of any information,
particulars, or errors in this publication, or any incorrect use of the product, whatsoever.
Copyright
Copyright and all other intellectual property rights in this manual and the associated software, and every
part of it (including source code, object code, any data contained in it, the manual and any other
documentation supplied with it) belongs to AVEVA Solutions Ltd or its subsidiaries.
All other rights are reserved to AVEVA Solutions Ltd and its subsidiaries. The information contained in
this document is commercially sensitive, and shall not be copied, reproduced, stored in a retrieval
system, or transmitted without the prior written permission of AVEVA Solutions Ltd. Where such
permission is granted, it expressly requires that this Disclaimer and Copyright notice is prominently
displayed at the beginning of every copy that is made.
The manual and associated documentation may not be adapted, reproduced, or copied, in any material
or electronic form, without the prior written permission of AVEVA Solutions Ltd. The user may also not
reverse engineer, decompile, copy, or adapt the associated software. Neither the whole, nor part of the
product described in this publication may be incorporated into any third-party software, product,
machine, or system without the prior written permission of AVEVA Solutions Ltd, save as permitted by
law. Any such unauthorised action is strictly prohibited, and may give rise to civil liabilities and criminal
prosecution.
The AVEVA products described in this guide are to be installed and operated strictly in accordance with
the terms and conditions of the respective license agreements, and in accordance with the relevant
User Documentation. Unauthorised or unlicensed use of the product is strictly prohibited.
AVEVA Solutions Ltd, High Cross, Madingley Road, Cambridge, CB3 0HB, United Kingdom
Trademarks
AVEVA and Tribon are registered trademarks of AVEVA Solutions Ltd or its subsidiaries. Unauthorised
use of the AVEVA or Tribon trademarks is strictly forbidden.
AVEVA product names are trademarks or registered trademarks of AVEVA Solutions Ltd or its
subsidiaries, registered in the UK, Europe and other countries (worldwide).
The copyright, trade mark rights, or other intellectual property rights in any other product, its name or
logo belongs to its respective owner.
Global User Guide
Contents Page
User Guide
Introduction to this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
Who Should Read This Manual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
How to Use This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
Other Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:2
Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
What is a Global Project? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
How Databases are Handled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
System and Global Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2
Networks and Communication Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:3
Off-line Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:4
Location Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:4
Global Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:5
How the Global Database is Updated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:5
The Transaction Database and the Pending File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:6
How Database Updates are Propagated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:6
What Happens if a Communication Link Fails . . . . . . . . . . . . . . . . . . . . . . . . . . 3:7
Database Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:8
Non-propagating Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:8
i 12.0
Global User Guide
ii 12.0
Global User Guide
iii 12.0
Global User Guide
iv 12.0
Global User Guide
Introduction to this Manual
AVEVA Global can be used to enhance projects created in either the AVEVA Plant or
AVEVA Marine group of products - henceforth known as the “base product” in this
document.
Global provides tools for administering base product databases across multiple geographic
locations. It ensures the integrity of data by automatically checking the project databases
and issuing incremental updates across all project sites.
This user guide describes the concepts that you need to know about before you start to
work with a Global project. It describes how to use Global to set up and administer a Global
project.
It is assumed that you will be working via the graphical user interface (GUI): the commands
underlying the interface are described in the Administrator Command Reference Manual.
For additional information about Global projects, see Running Global Projects.
1:1 12.0
Global User Guide
Introduction to this Manual
1:2 12.0
Global User Guide
Overview of Global
2 Overview of Global
AVEVA Global provides a simple and cost-effective administration and management system
for Global projects, where data is distributed across a number of locations. To the engineer
using the base product, it should be largely invisible that the project is distributed over many
locations.
The first step in Global is configuring a project as a Global project. There are a number of
parts to this configuration:
1. Specifying the locations.
2. Selecting the database files needed at each location.
3. Specifying when automatic data transfers can take place between locations.
Once this configuration has taken place, a Global daemon process will be started at each
location; it is the network communications between these daemons that ensure the
databases in the project are automatically kept up to date.
Note: Before changing the project network e.g. when creating, modifying, or deleting
locations, the Hub administrator should ensure the daemon is running, otherwise
there will be a substantial delay on SAVEWORK in contacting the daemon.
After you set up a Global project, you can use Data Access Control (DAC) to control users’
access to elements. For information about DACs in a Global project, see Data Access
Control and Stamps in a Global Project.
2:1 12.0
Global User Guide
Overview of Global
2:2 12.0
Global User Guide
Concepts
3 Concepts
This section describes the basic concepts of setting up a Global project using a small
project as an example.
3:1 12.0
Global User Guide
Concepts
• The Global database is propagated to the Satellite locations, but it can only be modified
at the Hub.
• Each location, including the Hub, also has its own System database. Each System
database is propagated to all locations automatically, even if the System database is
administered locally. A Satellite System database can be modified by an Administrator
who is at the primary location for that database. The primary location can be the
Satellite itself, or it can be a remote location, such as another Satellite or the Hub. If the
primary location is remote (not at the Satellite itself) an Administrator at the Satellite
cannot modify the Satellite’s System database. The Hub System database, like the
Global database, can only be modified at the Hub.
Note: The local system database filename is of the form prjsys, where prj is the project
code. There will also be a file of the form prjsys_loc for other locations: this is for use
in centralised administration (i.e. where one location administers all of the other
satellites remotely.).
• Once a project has been converted to a Global project, it cannot be converted back to a
standard project. In effect, a single-location Global project will behave like a standard
project, as far as most base product users are concerned. However, you can use the
REPLICATE SYSTEM STANDALONE command to replicate the project structure for a
Global project as for a standard (non-Global) project.
As explained above, if necessary, the System Administrator at the Hub or at a Satellite can
change a Satellite System database remotely, provided that the Administrator is at the
primary location for that database. However, any location can Query System database data
(about Users, MDBs and so on) at any other location.
When you make a project Global, a transaction database is also created, to store details
about the progress of issued commands. Global provides a facility so that you can monitor
the progress of Global commands, and, if necessary, cancel commands that have not been
carried out yet. See Monitoring Command Progress for details.
3:2 12.0
Global User Guide
Concepts
Hub
Hub A
Satellite Satellite
Satellite Satellite B C
Satellite
D
Hub
Satellite
E
Satellite Satellite
Satellite
Satellite
The relationship between locations is described in terms of a family tree: there are parents,
children, ancestors and descendants. For example, in Figure 3:1.: Examples of tree
structures for locations, the relationships between locations A, B, C, D and E are described
as follows:
• A is the parent of B and C.
• B and C are the children of A.
• B, C, D and E are the descendants of A.
• A, C and D are the ancestors of E
Every location except the Hub has a parent. The parent of each location is stored in the
Global database. The parent-child relationships define the connectivity of the
communications network, and allow the Global daemons to find the path from one location
to another.
3:3 12.0
Global User Guide
Concepts
Global supports this sort of network by means of a Group of locations. All locations within a
group must be able to communicate directly with all the other members of the group: the
following configuration is not allowed:
3:4 12.0
Global User Guide
Concepts
3:5 12.0
Global User Guide
Concepts
3:6 12.0
Global User Guide
Concepts
Before the automatic updating can start, you must create Update events between locations.
Update events define how often the Global daemons check the databases to see if there
have been any updates. The checks are based on the Session Number of the databases.
For example, location AAA has a direct on-line link to the Hub. A Design database PIPING/
PIPING-A which is primary at location AAA may be at session number 5, and at session
number 4 at the Hub. Therefore the database at the hub will be updated with the changes.
These changes may then be propagated to other locations that have copies of PIPING/
PIPING-A.
Note: If databases have been compacted by merging sessions or backtracking, the whole
of the most up-to-date database will be transferred. Therefore, if a database is large,
it is better to use the daemon to carry out remote merging. Remote merging at a
primary location automatically causes remote merging at the affected secondary
locations, so avoiding the need to copy the whole database.
Users reading the database will not see any changes until a session transfer is complete
and they do a GETWORK (if they are in a session).
Before After
3:7 12.0
Global User Guide
Concepts
If a communication link fails during an update, a database may be left with an incomplete
session at the end. In this case, only the last complete session is ever used, and so data
integrity is maintained.
Foreign databases can only be included in the project at the Hub. They can then be
allocated to other locations in the usual way. As in a standard project, a foreign database is
always read-only, and so it has no primary location.
Foreign databases are never propagated. If you want to propagate foreign databases, they
must be local databases in another Global project.
3:8 12.0
Global User Guide
Concepts
3:9 12.0
Global User Guide
Concepts
For example, myfile has been produced at Satellite AAA and is needed at neighbouring
location BBB. The user at AAA must ensure that myfile has been placed in directory
%EXP_BBB%. During the next scheduled update with BBB, this file will be sent to BBB, and
received in directory %IMPORT% at location BBB. A user at BBB can then use myfile. If
myfile is to be sent on to other locations, it will need to be copied into the export directories
at BBB for those locations.
3:10 12.0
Global User Guide
Setting up a Global Project
This section describes how to make a Global project. The starting point is a standard
project, created at the location which will become the Hub. The example used is a small
project with the project code ABC.
4.1 Preparation
Before you make a project Global, you must have completed the following stages (see the
Administrator User Guide for further details):
1. Create a standard project at the location that will become the Hub: that is, the
directories abc000 and abcmac must exist. You should also create directories abcpic,
abcdwg, abciso, and the subdirectories of abciso, in order to use DRAFT and
ISODRAFT.
2. The project environment variables must be set.
3. In the example standard (non-Global) project, the Teams, Users, DBs and MDBs have
already been created.
4. Setting up a Global project is very efficient and straightforward and you can carry out
the entire process locally on a LAN before distributing it to the Hub and Satellite
locations. Before you send the project to the satellite location, you need to modify the
satellite’s RHOST attribute. You must copy this change to the Global database
manually.
You can make a project Global without having created any Teams, Users, DBs or
MDBs.
4:1 12.0
Global User Guide
Setting up a Global Project
At this stage, the Hub does not have a transaction database. When you create the first
Satellite location from the ADMIN GUI, a transaction database will be created at the Hub
automatically. If you set your Global project up by giving commands from the command line
rather than using the ADMIN GUI.
Note: You must create a transaction database at the Hub before the Hub is initialised.
If you want to administer the current location, set the Administering option gadget to
LOCAL. To administer a different location, set the option gadget to the three letter code that
identifies the location.
The menu bar also shows whether DAC (Data Access Control) is switched on or off for this
Global project. See Data Access Control and Stamps in a Global Project for information
about using DAC in Global project.
Another change from the standard (non-Global) menu bar is that as well as the Lock button,
there is an Isolation button. Isolating locations is described in Isolation.
There are also more options on the menu bar, and under the Elements option button on the
Admin Elements form.
4:2 12.0
Global User Guide
Setting up a Global Project
If you look at the Databases version of the Admin Elements form, you will see that there is
a column containing + signs. The + signs show that the databases are all Primary at the
Hub. Secondary databases are marked with a - sign.
At this stage, the project is a single-location Global project.
Note: The Hub is identified by the word Hub in the second column of the list. An asterisk is
used to show the current location. These conventions are used on all lists of
locations on ADMIN forms.
Press Modify on the Admin Elements form, and the Modify Location form will be
displayed.
Note: once the location ID is set it is not normally allowed to change, however if the HUB is
not initialised it is possible to modify its location ID.
4:3 12.0
Global User Guide
Setting up a Global Project
The Name will appear on the Admin Elements form. For the newly created Hub, it will be
set to PROJECTHUB.
The Location ID is a three-letter code that identifies the location. For the newly-created
Hub, this will be set to HUB.
The Description is optional.
The Overwrite DB Users flag allows Global updates to copy and overwrite database files
even if they are locked. Global will not copy database files while there are users in the
project (as recorded in the COMMS database), even when Copy Overwrite is enabled. This
option is disabled by default.
Database copies cannot typically be carried out until all users have exited and the database
is unlocked. It is possible, for example after an EXPUNGE command for there to be no
users in the COMMS database and the database file locked. This would normally cause the
database copy to fail, unless Copy Overwrite is enabled.
Note: You must not enable this option if this project is to be used by other projects. There
may be valid database users who are using this database in another project.
4:4 12.0
Global User Guide
Setting up a Global Project
Parent is the name of the location which will be the Parent of the new location in the
communications network.
Note: The Hub (and off-line locations) do not have a parent. The parent of the Hub is
shown as Unset.
Group is used if you want the location to belong to a Location Group. Groups are discussed
in Location Groups.
Admin Loc identifies the administering location. If the location is administered locally, at the
location itself, this should be set to Local. If the location is administered from another
location, this should be set to the name of the administering location. The Local button will
set the administering location to Local.
All Global extracts are given an identifying number when they are created. Before you start
creating extracts, you should work out an extract numbering system.
Databases can be given numbers in the range 1-8191, and for each of these, working
extracts numbered in the range 1-8191 can be allocated. However, a working extract can
only be seen at its location (not globally), so to avoid database working extract number
clashes a working extract number range needs to be set for each location.
The Global extract range must be modified before setting working extract ranges. To set the
Global Extract Range select Settings > Global Extract Range.
Note: This is an example extract number range for illustration purposes. For a more
detailed explanation of extract numbers refer to section Extracts of the Running
Global Projects.
The Working Extract Number Range settings allow the extract number ranges to be
specified as explained above.An example of a completed Modify Location form is:
4:5 12.0
Global User Guide
Setting up a Global Project
Make any changes you need, and press Apply. You will be asked whether you want to
initialise the Hub now:
• If you press Yes, the Hub will be initialised with the current settings on the form. You
can change these settings later, if necessary. You should ensure that the Hub has a
transaction database before you initialise it.
Note: Once you have initialised the Hub, you cannot normally change the following
settings:
• Location ID
• Hostname
However, if you need to transfer the Hub to a different machine, (for example, because
of a systems crash) you can un-initialise the Hub and change these settings. In this
case, the Global database must be copied down to each Satellite before daemons are
restarted.
• If you press No, the values you have entered on the form will be stored, and you will
still be able to change them.
• If you press Dismiss, the form will be closed and any changes lost, as normal.
If you decide not to initialise the Hub at this stage, you can initialise it later by using the
Project>Initialise Location option. This option will generate an error if the location is
already initialised.
4:6 12.0
Global User Guide
Setting up a Global Project
4:7 12.0
Global User Guide
Setting up a Global Project
Connection will normally be on-line. For information about off-line locations, see Off-line
Locations.
Hostname is the identifier of the machine on which the Global daemon will be running at the
location.
Note: You should ensure that the Location ID and Hostname are correct. When you press
Apply on the form, the information is written to the Global database for the location,
in the Transfer directory for the location. Once the communications link has been
initialised, the only safe way to change the machine specified for the daemon is to
copy the Global database manually to the location. (You could do this by using
another data transfer method such as that described in Transfer of Other Data, on a
different project.)
The Parent option will be set to the Hub name, as this is the only option at this stage.
Groups are discussed in Location Groups.
Admin Loc identifies the administering location. If the location is administered locally, at the
location itself, this should be set to Local. If the location is administered from another
location, this should be set to the name of the administering location. The Local button will
set the administering location to Local.
All Global extracts are given an identifying number when they are created. Before you start
creating extracts, you should work out an extract numbering system. You use the Working
Extract Number Range to set the range of numbers that are available for working extracts
created at a specific location.
This example shows the form filled in for a location identified as OXF:
When you click Apply, the location and its transaction database will be created. You will be
prompted to confirm that you want all the databases that exist at the Hub to be copied to the
Transfer directory, ready for taking to the location. For this example, we will assume that this
is confirmed. For more information about making the decision, see Database Allocation.
4:8 12.0
Global User Guide
Setting up a Global Project
The location’s transaction database is already primary at the Satellite. Other databases will
be transferred to the Satellite as secondary databases. You can change the primary location
after:
1. The files in the Transfer directory have been installed at the Satellite
2. The Global daemons have been started at the Hub and the Satellite
3. The Satellite has been initialised.
If location generation includes copying all databases which exist at the Hub to the
transfer area, it can take some time, according to the amount of data being copied.
Note: Locations must be installed in descending order: that is a location must be installed
before any of its children.
Once the project has been installed at the new location, the next steps are to start the
Global daemon (see the following section) at the new location, and then to initialise the
location (see Initialising a New Location). Then the Administrator at the Satellite can create
Users and MDBs.
If you are simulating the Location creation as a training exercise, you can copy the files to
another directory on your local network. Set up the normal project directories and set the
project environment variables, as if you were working at the new location.
Note: The service normally runs as an administrator, and does not inherit any variables
from the user login. This means that all variables required by the service must be set
up in the batch file used by the service.
The AVEVA Support website contains important information about the IT Configuration
required for Global.
If the daemon is to be installed on a network behind a firewall or DMZ it may be necessary
to conduct additional post configuration, see Firewall Configuration in Running Global
Projects.
4:9 12.0
Global User Guide
Setting up a Global Project
admind.exe Libmmd.dll
project files (inc *vir.dat) demonservicesingle.exe
attlib.dat demonservicemulti.exe
Libifcoremd.dll singleds.bat
dop.exe multids.bat
message.dat
• If transfer of other data files is required (see Transfer of Other Data), then import
(IMPORT) and export variables (EXP_XYZ for export to location XYZ) must also be set
up.
Note: If the project is using Areas, these will also need to be set along with the other project
variables.
This command must be run from a directory located on the local machine for the
service to install. If it is executed from a mapped drive or UNC pathname then the
service will not start when requested.
4:10 12.0
Global User Guide
Setting up a Global Project
Example:
4:11 12.0
Global User Guide
Setting up a Global Project
The command in the singleds batch file to start or stop the daemon uses parameters. Do not
replace parameter %1 by an explicit ‘start’, since this batch file is also used when stopping
the service.
To remove the service, in a command line window type:
DemonServiceSingle /remove
If for any reason, the service will not start, it is possible to run the service from a command
line window using:
demonServiceSingle /debug
This will assist in identifying the cause of the problem (for example, Project directory not set
up).
Note: The debug option runs the service program from the current user, whereas the
service itself runs as a local system administrator. If the service fails to start or does
not run the daemon, try running the batch file from a command line window (first
unset variables in your command window):
Note: This command must be run from a directory located on the local machine for the
service to install. If it is executed from a mapped drive or UNC pathname then the
service will not start when requested.
4:12 12.0
Global User Guide
Setting up a Global Project
If for any reason, the service will not start, it is possible to run the service from a command
line window using:
DemonServiceMulti /debug
This will assist in identifying the cause of the problem (for example, Project directory not set
up).
Note: The debug option runs the service program from the current user, whereas the
service itself runs as a Local system administrator.
The following text describes how to configure a Global daemon service on Windows NT and
Windows 2000. The general principles apply for Windows XP. For specific information on
how to select a service on Windows XP, refer to the Windows on-line help.
Select Start>Settings>Control Panel>Administrator Tools, and then select Services.
The following Services form will be displayed, and the Global services you have just set up
will be listed.
Select AVEVA Global Multi Project or AVEVA Global Single Project right click and select
Start. (Once the service is running, you can right click and select Stop to stop it.)
Note: To run the daemon as a service, the project directory and the daemon files must be
on a local drive. The installation of the service must also be carried out locally. See
the Global Installation Guide for full information.
4:13 12.0
Global User Guide
Setting up a Global Project
If you are using multiple projects, the Global daemons for all the projects will be started. You
cannot stop and start individual daemons: if you need to stop one daemon but not the
others, stop the service, edit the file to remove the daemon you want to stop, and then start
the service again. If you right click and select Properties on the Services form, you will see
another form which allows you to start up the service automatically when the computer is re-
booted.
You can check whether the daemon is running by starting up the Task Manager and
selecting the Processes tab. Look for the process named admind. In a multiple project
service, there should be one admind process for each project.
4:14 12.0
Global User Guide
Setting up a Global Project
You can check that the location has been initialised successfully. At command level, give the
commands:
/GLOC Make the location (in this example, /GLOC) the current element.
GETWORK Refresh view of System database. You must give this command before
you can see changes made to the Global database by the Global
daemon.
Q ATT Query the attributes of the location: LINIT will be TRUE if the location
has been initialised.
Note: The Hub Administrator will have to GETWORK to see the initialisation as complete,
because the daemon (which is effectively another ADMIN user) will have written to
the Global database.
Note: A database can only be primary at one location: setting the primary location
automatically makes the database secondary at all other locations.
If you select one of the databases from the Admin Elements form and press Modify on the
Admin Elements form, you will see the Modify Database form.
Note: The options that are inactive on this form are the attributes of the database that
cannot be modified once it has been created.
4:15 12.0
Global User Guide
Setting up a Global Project
Select the pull-down button at the right of the Primary Loc. text box, and the Primary
Location form will be displayed.
4:16 12.0
Global User Guide
Setting up a Global Project
Select a location, press OK, and then Apply the Modify Database form. The database will
now be primary at the Satellite, and secondary at the Hub, as shown by the - sign in the
column on the Admin Elements form for the Hub.
4:17 12.0
Global User Guide
Setting up a Global Project
Isometric Production is carried out at Location B. The Pipework Design and Catalogue
databases will be available at Location B, and the ISODRAFT database must be primary at
Location B. It will not be required at Location C.
You will need to allocate the databases, and set their primary locations, as shown in Figure
4:2.: This is the allocation which we want to achieve.. The databases which are primary at a
location are marked with a +. This is the convention which is used on the forms in the GUI.
Location B needs the Steelwork Catalogue and the Steelwork Design database. Because it
is also the link in the communication chain between the Hub and Location C, Location B
must also have the Pipework and Drawing databases present, because it is the route by
which updates are transferred between the Hub and Location C.
comms comms
Location A Location B Location C
Figure 4:3. This diagram shows the databases existing at Locations A and B, just before Location C
is created.
4:18 12.0
Global User Guide
Setting up a Global Project
Figure 4:4. This diagram shows the databases at all three locations just after Location C has been
created.
Figure 4:5. Now the Hub Administrator has de-allocated the ISODRAFT database from Location C
because it is not required there.
Note: That DRAFT/DRAFT must remain allocated to Location B. The DRAFT database has
been made primary at Location C, and the ISODRAFT database has been made
primary at Location C.
Note: You can display information about the locations you have already created by
selecting Query>List>Locations, which displays the List Locations form.
4:19 12.0
Global User Guide
Setting up a Global Project
The timing of Update events is particularly important between the members of a group.
Note: Update events only control the frequency with which model databases are updated.
When commands affect the Global or System databases, the changes to the
databases are propagated as quickly as possible to the required locations.
To create an Update event, select Updates from the Elements button on the Admin
Elements form, and press Create. You will see the Create Update Event form.
Fill in a Name, which must be fewer than 32 characters long and unique within the project
location.
The Description is optional. It can be up to 120 characters.
The Update Location list shows all the locations that can share an update event with the
current location. They are on-line locations which are one of the following categories:
• The parent location of the current location.
• A child of the current location.
• A member of the same location group as the current location. See Location Groups, for
information on groups.
The gadgets in the Update Settings frame relate to the parameters of the
communications process.
The Frequency text box controls the frequency at which updates will take place. These may
be daily, hourly, weekly, monthly or a combination. The value entered consists of five fields
4:20 12.0
Global User Guide
Setting up a Global Project
which are separated by spaces. The button immediately to the right of the text gadget allows
the field values to be specified separately using several child forms.
Max. Retries can be set to a number between 1 and 100. This is the number of retries the
communication daemon will make in the event of unsuccessful communications.
Retry Interval can be set to a value in the range of 1 to 14400. This value is the time in
seconds between communication retries. If the communications daemon cannot connect to
the remote location, it will wait this number of seconds before attempting to reconnect. It will
continue to attempt to reconnect until the maximum number of retries is exceeded.
Transfer Scripts
You can enter the names of script files in the two Transfer Script text boxes. The scripts will
be run Before or After the update procedure. The scripts are optional and they do not both
have to be set.
The scripts could be used, for example, to transfer selected plotfiles.
When a script is run it will be supplied with two arguments, the three-character ids of the
current location (A) and the remote location (B), in that order.
It is possible to run scripts at the remote location. To do this, you should create an update
event at the current location with the Frequency text box left blank, and the Transfer
Scripts text boxes filled in. When an update occurs between A and B, the scripts will be run
at B. The arguments will be reversed (B, A).
Note: When an Update event is created or deleted, it may take some time to come into
effect. There is a possible delay of up to 15 minutes before the update information is
re-read from the System database. If necessary, this delay can be reduced by
stopping and re-starting the daemon.
In addition to the above, the transaction database will also be checked regularly for stalled
commands.
You can also update databases manually. See Unscheduled Updates for more information.
Note: You should schedule updates to allow time for general housekeeping activities, such
as database merging. For example, you might set up scheduled updates to run only
between Monday and Saturday to allow merges to take place on Sundays.
4:21 12.0
Global User Guide
Setting up a Global Project
4.13 Conclusion
You now have a Global project up and running. The following chapters describe other tasks
that the System Administrators at the Hub and the Satellites will have to carry out.
4:22 12.0
Global User Guide
Hub Administration
5 Hub Administration
Creating Global projects and locations and configuring communication daemons have been
described in Chapter 4. This chapter adds to the information, and describes the other tasks
that will need to be carried out at the Hub. These are:
• Controlling database allocation.
• Changing the primary location of a database.
• Changing the Hub location.
There are also several tasks that the Hub Administrator can carry out remotely for a
Satellite: some of these tasks are also described in Local Administration, as they are
essentially local operations. These tasks are:
• Remotely merging changes.
• Remote locking and isolation.
• Remote synchronisation of databases.
• Remote data recovery.
• Remote removal of phantom users and elements.
• Remote integrity checking of databases (DICE).
The Hub Administrator is also responsible for the normal administration of databases
that are primary at the Hub, and the creation of Users and MDBs for the location that
happens to be the Hub. All these tasks are described in the Administrator User Guide.
Note: Refer to Database Access Control at Satellites for further detail about satellite DAC
administration.
5:1 12.0
Global User Guide
Hub Administration
Note: All databases must exist at the Hub. Satellites do not require a complete set of all the
project databases, but a database must exist at all locations in the network between
the Hub and any locations where it is allocated.
5:2 12.0
Global User Guide
Hub Administration
The Project Databases scrolling list shows all the databases in the project.
• + means Primary at the current location
• - means Secondary at the current location
• * means a Foreign database (propagation of Foreign databases is under the control
of the Foreign project)
The user can Sort By a specific column in the list such as Name or Type.
The Filter gadget can be used to filter the list to show only databases with a Name that
includes the input value. An asterisk (*) can be used as a wildcard. Values entered into the
Filter gadget are case sensitive.
The Allocation details window contains two scrolling lists:
• Project Location shows all the locations to which the database is not allocated.
• Allocated To shows all the locations to which the database is allocated, and whether it
is primary or secondary at that location.
Note: The indentation in the list represents the tree structure of the communications
network.
5:3 12.0
Global User Guide
Hub Administration
The Project Locations scrolling list shows all the Locations in the Project.
The Database Allocation window contains two scrolling lists, showing the databases which
are De-allocated and Allocated to the selected Location. The Clear button clears the
selection from the associated list.
Use the arrow buttons to change the allocation.
The Copy Allocation button allows you to copy the allocation of databases from another
location.
The Processing Options are as follows:
• If the Include descendants when de-allocating databases option is set, the
Databases which are allocated to descendants of the current Location will be de-
allocated. If this option is not set, and you try to de-allocate a Database which is also
allocated to descendants of the current Location, the Database will not be de-allocated.
This is because a Database must always be allocated to all Locations between the Hub
and its most remote Location.
• The ‘Allocate All’ to allocate non-propagating databases option is only available if
all databases have been allocated to a location. If you require this allocation to include
non-propagating databases, set this option. If non-propagating databases are not to be
allocated, leave it unset. If the option is set, you will be required to confirm the
allocation of non-propagating databases to the location when you Apply.
• If the Show errors as summary at end of processing option is set, a summary of
errors is shown at the end of processing.
5:4 12.0
Global User Guide
Hub Administration
• If the Keep MDBs while de-allocating DBs option is set, then the database is de-
allocated without removing it from MDBs at the satellite. This may be useful as part of
certain house-keeping procedures, such as a temporary de-allocation to reconfigure
the database. This database will be deferred automatically by the system when a user
selects an MDB with a de-allocated database. This option should not be used when the
database is being removed permanently.
getwork
/Oxford
1 (go to the DBALL element, which is the first element in the member list)
q mem
Note: Do not attempt to re-allocate a database unless you are sure that the allocation has
failed - check that there is no entry in the transaction databases (by selecting
5:5 12.0
Global User Guide
Hub Administration
The preferred order of database types is achieved by using the Automatic re-order button:
this orders the databases according to type as follows:
• Dictionary databases
• Properties databases
• Catalogue databases
• Design databases
• Draft databases
5:6 12.0
Global User Guide
Hub Administration
This button also arranges Extract databases in hierarchical order, so that the Master
precedes any child extracts.
You can order the databases manually using the Allocation Order part of the form.
Select a database which you want to move in the list.
Use the arrow buttons to the right to move it up or down the list.
To move a database from one row to another, select that database in the list, press the
Select row to move button, then select the row you want to move it to, and press the Move
to button.
5.2.6 De-allocation
When a database is no longer needed at a Satellite, it can be De-allocated.
• You cannot de-allocate a primary database: you must first change the primary location.
If you make a database secondary while a user is writing to it, the user will be able to
write to the database until a module change or a GETWORK. The database will not be
re-allocated until the user quits or changes to an MDB that does not include that
database.
• You cannot de-allocate a database from a location which is the parent of the primary
location. A database must be allocated to all locations between the Hub and its primary
location.
• If users are reading a database at a Satellite when it is de-allocated from that location,
then the database will not immediately be deleted from the Satellite. The de-allocation
transaction will be stalled until all users at the location exit their sessions or change to
an MDB that does not include the database. The database will then be de-allocated
and the database files deleted. (However a location can still be deleted even if it still
has its transaction database allocated).
Note: Under normal circumstances, you should not de-allocate a Satellite’s transaction
database from the Satellite. This facility is only provided for recovery purposes, or to
allow a Satellite to be deleted.
See What Happens When Databases are Allocated for a description of the allocation and
de-allocation mechanism. (See also the Administrator Command Reference Manual,
DEALAL and DEALDB attributes.)
The procedure for de-allocating a database is shown in the following diagram:
5:7 12.0
Global User Guide
Hub Administration
5:8 12.0
Global User Guide
Hub Administration
5:9 12.0
Global User Guide
Hub Administration
As picture and neutral format files are very large and do not normally require propagation,
these files are non-propagating by default. In general, it is only necessary to propagate
picture associated with project-wide DRAFT overlay sheets.
Transaction databases are very large and should not normally be propagated. Transaction
databases are non-propagating by default.
Working extracts are always non-propagating databases.
This form lists all the initialised locations defined in the project. Select the new primary
location from the Project Locations list.
It is possible to schedule the change of primary location for a given time.
Note: This operation will update the Global database without waiting for the next Update
event, but it still may not take place immediately. The primary location cannot be
changed until all users at the old primary location exit their sessions or change to an
MDB that does not include the database.
5:10 12.0
Global User Guide
Hub Administration
The Transient Databases list gadget contains a list of project databases that have their
PRVRF (previous reference) attribute set. This attribute is only set when a change of
primary location is in progress. The attribute is reset to null when the change of primary
location is complete. Several databases can be selected.
Note: If, after the form is displayed, the daemon completes a command that affects the list
of databases, the list can become out of date. In this situation, an attempt to recover
the primary location for the database will fail (because, for example, the change of
primary location has been completed successfully).
Note: This is a command line operation only, as you will have to re-enter ADMIN to display
the correct version of the GUI at both the new Hub and the old Hub. It also provides
protection from initiating this operation accidentally.
Global can handle and recover from communication failure when changing the Hub, but we
recommend that you take the following preliminary steps to minimise the risk:
• Ensure that the daemon is running at both the current Hub and the Satellite which will
become the new hub by selecting Query>Global Status>Communications or by
issuing a Ping command. This can be achieved from the Admin, Design, Draft or
Spooler module.
5:11 12.0
Global User Guide
Hub Administration
• Ensure that you have the project at the original Hub backed up and at least the Global
database (prjglb) at the Satellites backed up.
The following illustrates the sequence of tasks:
1. Make sure that all databases are allocated to the new Hub by using one of the
Data>Database Allocation options. (This must include all transaction databases.)
2. You may like to synchronise the databases at the location that is about to become the
new Hub. This can be done locally at the Satellite, or remotely from the current Hub.
See Synchronisation.
3. Change the Hub location: display the command window, and enter the command:
hublocation loc
For example:
hublocation OXF
This process may take some time to complete. The name of the Hub location is
changed in the Global database. The Global database becomes secondary at the old
Hub and primary at the new Hub.
Note: The change of Hub location cannot complete while there are administrators logged in
at the old or new Hubs.
4. Confirm that the Hub change has been successful by checking the HUBRF of /*GL
attributes of the two locations. For example, if you are changing the Hub from London
to Tokyo:
Navigate to /*GL at the old Hub 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. (As a secondary effect, the LOCRF of /London should now be /Tokyo.)
Then navigate to /*GL at the new Hub and Query its HUBRF:
/*GL
Q HUBRF
The HUBRF should also be set to the name of the new Hub: in this example, /Tokyo.
(As a secondary effect, the LOCRF of /Tokyo should now be Nulref.)
In the event of failure, use the Data>Recover>Hub Location option which will be
available at the original Hub location. Try again when communications have been
restored. The Hub recovery option should be used with extreme caution, as otherwise it
is possible to end up with two Hubs. If this happens, no other administration should be
done until the situation is resolved. For further information, see Running Global
Projects.
Note: Recovery of a hub location is normally done automatically if a hublocation operation
fails - check the progress of the command in the transaction database. An explicit
recover operation applied to a hub location Db should only be used as a last resort.
It is normally only required when daemons are down or for offline locations. (See also
the Administrator Command Reference Manual (HUBLOCATION and RECOVER,
commands)).
5. Exit from ADMIN and re-enter. The GUI will be started as a Satellite.
6. The allocation lists of secondary databases at the old Hub and locations on the
communications network between the old and new Hubs need to be reviewed and any
redundant databases de-allocated.
5:12 12.0
Global User Guide
Hub Administration
Output to the Global daemon windows will indicate whether the location is now the Hub
or a Satellite.
The advantage of using groups is that it gives direct links between local locations. So
communication is direct between each location in a group of (for example) Australian
locations rather than the information travelling around the world through several locations,
and thus taking longer to arrive.
There is one location in the group which is the Root: this is the first location on the route
from the Hub to the group.
• All the other locations in the group must be children of the root.
• All the locations in the group must have direct communication links with each other.
• Each member of the group can have children which are outside the group.
• Only the root can have a parent outside the group.
5:13 12.0
Global User Guide
Hub Administration
A group is set up by creating it using the Admin Elements form, and then adding the
locations which will become its members using the Group Membership form, which is
displayed when you press the button at the right of the Group text box on the Create/
Modify Location form.
To replicate the project structure, a macro may be created that can be run into ADMIN at
a later date.
The macro created must be run in two stages - firstly to create the basic project structure
and locations, secondly to allocate databases. Comments in the macro indicate where the
split should be made.
To activate the macro, use one of the following menu options.
• Project>Replicate>Project Structure replicates the structure of a Global project.
• Project>Replicate>Standalone replicates the project as a standard project, omitting
references to locations and communications.
The File Browser form is displayed so that you can specify the macro filename. The
default filename is $PDMSUSER/RecreateProj.mac.
Note: The following option can be used at a Satellite:
5:14 12.0
Global User Guide
Hub Administration
The effects of these operations are the same as if they were carried out locally. Generally,
you can use the Remote options from the Hub, the Satellite itself, or the administering
location. However, you can use Remote>Integrity Checker from any location.
Note: Extract databases cannot usefully be checked in isolation (using CHECK FILE),
since access to the extract owner is required. This means that REMOTE CHECK
cannot be used on Extract databases (other than the extract master).
For details on how to carry out these tasks, see the sections below.
Use The Databases of option button to select the remote location for which the database
sessions are to be merged.
You can merge the changes to the System databases, or to a Single Project database. If
you choose Single Project database, select a database from the Available databases list.
5:15 12.0
Global User Guide
Hub Administration
You can merge All Changes, Changes Up to or Changes After a given time, date or
session number.
The Rebuild list button is used to update the list of databases. For example, if a new
database has been created while the form is displayed, the list will not be updated until the
form is closed and re-displayed, or the Rebuild list button is pressed.
To schedule a time for the merge to take place, click on Timed Merge to display the
following window.
Enter a time in the format HH:MM:SS and a date in the format DD MMM YYYY.
Click Apply to store the input values.
Click Cancel to close the window.
After specifying the sessions to merge, press the Apply button to merge changes. Some
session data will be deleted. The sessions remaining are those that you have either kept
deliberately, or stamped sessions, as these are considered permanent and are not merged.
Each time a user does a SAVEWORK, a new dB session is created, so for any working day
there may be hundreds of sessions added to a multiwrite database. These can be merged
into one session for each day. This would keep the number of sessions per year to a
manageable 300-400 sessions. Older sessions could be further compressed to weekly or
even monthly increments, whereas newer data compression could be delayed by a day or
merged into hourly increments, prior to the daily merge, to allowing more accurate
backtracking if necessary.
The above information is given as a guideline for consideration but each organisation needs
to decide on there own course of action.
Database Stamps
Database sessions included within a Stamp are considered permanent and are not removed
when a MERGE CHANGES command is given.
5:16 12.0
Global User Guide
Hub Administration
You can Query the Lock and Isolation states of the location selected in the list by switching
the Lock and Isolation buttons on and off. If a button is on when you press Apply, the
relevant information will be shown next to the Lock and Isolation gadgets. When the form
is first displayed, these gadgets will be set to Unknown.
The Remote>Lock & Isolation option allows the System Administrator at the Hub or a
Satellite to control the lock and isolation states of on-line Satellites. The Global daemons
must be running.
5:17 12.0
Global User Guide
Hub Administration
The process is interactive, and you must wait for a response (or time-out) before continuing.
This option is only available at an on-line Hub.
The Lock State and Isolation State option buttons show the current state of the selected
location.
The Message text gadget allows you to send a message to the Free User at the remote
location if one of the states is changed. The maximum length of message is 80 characters.
The message will only be sent if the commands succeed.
5:18 12.0
Global User Guide
Hub Administration
5:19 12.0
Global User Guide
Hub Administration
From the Recover From drop down select the location for which the databases are to be
recovered from.
Selected Location If Recover From is set to Selected Location then the user
must first choose a location from list of locations that will
become available directly below the Recover From drop
down. The specific database can be selected from a list of
databases.
After selecting a Recover From location, use the Type of Databases option to select which
type of databases you want to recover from the selected location. And then select a
database from the list.
From the Recover Database to location drop down select a location to copy the selected
database to.
5:20 12.0
Global User Guide
Hub Administration
Note: The options available in the Recover Database to location will depend on the
database selected
Use the Expunge at Location option button to select the remote location at which you want
to expunge items.
Set the Type of Database option button to User or System, then select the database claims
and/or users to expunge from the lists displayed.
If System is selected, the for Location is activated, to allow a Remote Expunge of System
databases of administered locations.
Press the Apply button to expunge the selected items. Any databases that are in use at the
remote location will not be expunged.
5:21 12.0
Global User Guide
Hub Administration
Use the Databases at Location option button to select the remote location where you want
to check the database integrity.
The Check options allow you to choose which databases you want to check. If the option
button is set to Selection, you can pick the databases you want from the list. All selects all
the databases in the list, and Clear clears the selection.
The Settings options control the types of check carried out, For information about these
options, refer to the section on the Database Integrity Check form in the Administrator User
Guide.
You can output the reports generated by DICE to your Screen or to a named File.
5:22 12.0
Global User Guide
Hub Administration
Either from Admin Main Query menu bar: Query>Project>Remote Filedetails…Remote Last
Session… or Popup menu in Admin Element form: Query>Remote Filedetails… Remote
Last Session…
Selecting the Remote Filedetails option displays the form below.
The main function of this form is to get the file details of one or more databases for the
current or any other location.
Selecting the Remote Last Session option displays a similar form with results relevant to the
last session:
5:23 12.0
Global User Guide
Hub Administration
In both forms, the Location option lists all the online (not offline) locations. On selecting a
location, all the databases of that location will be listed. If the Daemon of the selected
location is not working, the Apply button is de-activated and the status of daemon will
appear adjacent to the button. While the system establishes connection with the Daemon of
the selected location, the status file informs the user. Select one or more databases from the
list and press the Apply button. Now the resulting file detail or session detail of the selected
database(s) is listed on the right of the form, along with the database name – see below.
Results can be stored by entering a file name and pressing the Report button.
• The user can Sort By a specific column in the list such as Name or Type.
• The Filter gadget can be used to filter the list to show only databases with a Name that
includes the input value. An asterisk (*) can be used as a wildcard. Values entered into
the Filter gadget are case sensitive.
• If the daemon is not in contact for the selected location, the Apply button is de-activated
and an error shown adjacent to it, as shown below. The Test Communication… button
is an additional utility to check the Communication status of the daemon, so that the
user can check it before selecting the Location. This shows the Test Project
Communication form.
5:24 12.0
Global User Guide
Hub Administration
5:25 12.0
Global User Guide
Hub Administration
5:26 12.0
Global User Guide
Local Administration
6 Local Administration
The administration tasks described in this chapter may need to be carried out at the Hub or
at the Satellites. Operations on constructor databases, such as merging changes, locking,
isolation, data recovery, synchronisation, expunging and integrity checking can be carried
out remotely at a Satellite by a System Administrator, as described in Remote Operations.
6.1 Locking
Locking a Global project at a location has the same effect as locking a standard project: it
prevents users entering the project. Local locking is done in the normal way, using the
button on the main ADMIN menu bar.
You can remotely lock or unlock any or all of the project locations from the Hub, the Satellite
itself, or from the administering location, using the Remote>Locking and Isolation option.
See Remote Locking and Isolation.
6.2 Isolation
Isolation prevents any updates or database-related operations taking place at the isolated
location. Isolation may be necessary, for example, if corrupt data appears at any location.
Note: Isolating a location prevents all its descendants from connecting with the isolated
location. However, the descendants are still able to connect with each other.
You can remotely isolate or re-connect any or all of the project locations from the Hub, the
Satellite itself, or from the administering location, using the Remote>Locking and Isolation
option. See Remote Locking and Isolation.
6:1 12.0
Global User Guide
Local Administration
6.3.1 Synchronisation
You can remotely synchronise locations from the Hub, the Satellite itself, or from the
administering location, using the Remote>Synchronisation option. The form is similar to
the form for the current location, described below.
Select Data>Synchronise on the main ADMIN menu bar, and the Synchronise
Secondary Databases form will be displayed.
You can synchronise all or selected secondary databases at the current location with:
• The corresponding databases at the primary location; or
• secondary databases at a selected location.
All the intermediate locations will be updated. A message will accompany any updates
to intermediate locations.
Set the With Databases at option gadget to Primary Locations or Selected Location. If
you choose Selected, you can select one or more databases from the Secondary
Databases list, which shows all the secondary databases at the current location.
You can also use this form to synchronise a secondary Global or System database (that is,
a Global or System database at a Satellite) with its primary location or with a secondary
database at another satellite.
6:2 12.0
Global User Guide
Local Administration
6.3.2 Updates
The Update option is a two-way process: databases at the current and the selected location
will be updated so that they are in step with each other, unlike the Synchronise option
which only updates the current location.
Select Data>Update on the main ADMIN menu bar, and the Unscheduled Database
Update form is displayed.
The Update With Location list contains a list of all locations with which updates are
possible: that is, on-line locations that are the parent, a child or a member of the same
group. Only a single location can be selected.
The Allocated Databases list contains all the databases allocated to the current location.
Set the Update option button to Selected, and select one or more databases from the list,
or set the Update option button to All. If you choose Selected, you can use the All and
Clear buttons to select all the databases in the list, and to clear the selection.
6:3 12.0
Global User Guide
Local Administration
This operation is very similar to synchronisation, except that complete databases are
propagated instead of updates. It is not available at off-line locations.
• It is important to remember that recovering a database could result in loss of work. The
main object when a recover is carried out is obviously to restore the database and
minimising the work loss.
The database may not become up-to-date immediately, but it will be updated in the
normal course of updates, or it can be synchronised with the primary location once the
file is re-established.
You can remotely recover databases from the Hub, the Satellite itself or from the
administering location, using the Remote>Recover Database option. The form is similar to
the Recover Databases form for the current location, described in The Recover Database
Form.
6:4 12.0
Global User Guide
Local Administration
• Restore from backup if all secondary databases are older than backups or if they had
not been synchronised with the primary database before it was corrupted.
• Restore from a secondary location if it has an uncorrupted and newer database than
the one in the backup. (You should restore from the latest secondary database.)
6:5 12.0
Global User Guide
Local Administration
Use the Recover Database to Location form to recover a database from one location to
another.
From the Recover To drop down select one of the following options:
Selected Location If Recover To is set to Selected Location then the user must
first choose a location from list of locations that will become
available directly below the Recover To drop down. The
Selected Location database will be overwritten with a specified
current location database.The specific database can be
selected from a list of databases.
Using the Type of Database drop down the user can filter the list of databases to show
either System Databases or User Databases.
6:6 12.0
Global User Guide
Local Administration
After making a selection from the Database Type drop down the user will be able to
highlight a specific database from a list. The highlighted database will be the source
database to be recovered to the locations specified in the Recover To drop down.
The user can Sort By a specific column in the list such as Name or Type.
The Filter gadget can be used to filter the list to show only databases with a Name that
includes the input value. An asterisk (*) can be used as a wildcard. Values entered into the
Filter gadget are case sensitive.
Click Apply to recover the selected database or click Dismiss to close the form.
6:7 12.0
Global User Guide
Local Administration
Free Users The Free Users will be shown in the top window
Users at The locations will be shown in the Project Locations window. The
Current, All and Clear buttons can be used to specify the current
location, all locations or to clear the selection.
6:8 12.0
Global User Guide
Local Administration
If you need to give commands and make changes to a System database, you must first
ensure that the database is primary at your current location. For details, see Changing the
Primary Location.
From the ADMIN menu bar, set the Administering option gadget to the location where you
want to administer the System database.
Once you have selected a System database, you can carry out most administrative tasks,
including housekeeping tasks such as the following:
• Merging changes.
• Removing phantom users and elements.
• Checking the integrity of databases (DICE).
For information on how to remotely merge changes, remove phantom users and check
database integrity, and carry out other remote operations, see the relevant sections in Hub
Administration.
Note: You will not be prompted to carry out a Repair as a result of the system finding de-
allocated databases. This results from the Keep MDBs option while de-allocating
DBs (used during house-keeping procedures)
The displayed form allows for a Repair or a Repair Check, with output to screen or file.
Note: When a project database is merged, the database sessions will be lost. Thus the
ability for Global to send only session changes is lost too.
It is therefore recommended that you remotely merge a project database, as this also
synchronises and merges the database at all secondary locations automatically (unless the
database is non-propagating). This prevents propagation of the entire database on the next
update. For information on how to remotely merge a database, see Remote Change
Management.
6:9 12.0
Global User Guide
Local Administration
Database merges should be executed at times when users are not accessing the database.
It is also recommended that there should be no users at secondary locations, since the
merged database cannot be received until these users have left the database.
6:10 12.0
Global User Guide
Monitoring Command Progress
In Global, commands that are issued at one location, but have an effect at another location,
are processed in parallel. This means that the next command in a series of commands may
be initiated before the previous one has finished. However, there are situations where it may
be essential for one command to execute completely before the next one is carried out.
To enable you to monitor the progress of Global commands, Global stores details of issued
commands in a transaction database. Transaction messages are generated in the
database each time the progress of the command changes. Global provides a facility that
enables you to view these transaction messages, and, if necessary, cancel commands that
have not been carried out yet.
For information about the structure of the transaction database, see the Administrator
Command Reference Manual. For information about how messages are processed, see
Running Global Projects.
The Command Transactions scrollable list displays the Issue Date, Status, and other
information about each Command issued. This combination of details for a command is
known as a command transaction. As a command progresses, the information displayed
7:1 12.0
Global User Guide
Monitoring Command Progress
in the Command Transactions list is updated. If desired, you can view details of all the
transaction messages for a specific command, as explained in Viewing Transaction
Messages.
You can use the Filters on the left hand side of the form to control exactly which transactions
are displayed in the Commands Transactions list. An Administrator can choose some
additional values for filters that are not available to general users.
Press Initialise Filters if you want to reset all filters to their default state.
You can use the following filters:
• Use User to specify which user’s commands will be displayed. General users can only
view their own commands. An Administrator can view commands for All Users, and
also commands from the ‘users’ Local Daemon, Remote Daemon and Timed Updates.
For example, by selecting Remote Daemon, the Administrator can view the remote
commands passing through the location.
• Use Module to display commands issued from that module only.
• Use Command to specify which type of commands will be displayed. The default is All
commands. The option list contains the most commonly used Global commands. If you
want to display a different Global command, set this option to All commands and use
the Text filter to ensure that only the required commands are displayed.
The display can be filtered so that only Local commands are listed. Local commands are
defined as those commands that take place entirely locally, For example, an Extract claim
made when an owning extract database is at the same location.
The display can also be filtered so that only Satellite commands are listed. Satellite
commands are defined as those commands that take place via the Global daemon (i.e. not
locally), For example, an Extract claim made when an owning extract database is NOT at
the same location.
It is possible to switch local command recording on or off. See Transaction Audit Trail in
Running Global Projects.
• Use Status to specify which status the displayed commands should have. For example,
you may decide to display Waiting commands only. The default is All status. See below
for descriptions of the different statuses.
• Use Pass/Fail to set the list of commands to display only those commands that passed
(were successful), or only those that failed, or all commands regardless of whether they
passed or failed. A "1" in the Passed column of the commands list indicates that the
command has completed successfully. A "0" indicates that it has not.
Switch on Display flagged commands only to filter the commands so that you view flagged
commands only. You can flag certain commands with your own text, to make it easier for
you to follow them up.
Checkmark the Text checkbox if you want to filter the commands based on specific text
appearing within them. Enter the required text in the text box. For example, you might
enter /PIPE7.
• Use Start Date to specify the start date from which commands should be displayed.
The default is yesterday.
• Use End Date to specify the end date up to which commands should be displayed. The
default is today.
Press Apply Filters to apply the filters to the Command Transactions list and update the
display, so that only transactions that meet the filter criteria are shown.
As there may be too many command transactions to display at once in the list, you can
specify the number of Commands per page. You can also select to show transactions
7:2 12.0
Global User Guide
Monitoring Command Progress
either in Date Order or Reverse Order. If there are several pages of commands, use the left
and right buttons to display the different pages, or enter the number of the required page
directly in the Page text box.
If the form is displayed for several minutes, press Update Transactions to update the
Command Transactions list from the transaction database, re-applying the filter criteria.
The Status of a command in the Command Transactions list can be any of the following:
In Progress - the command is being executed currently. A command that does not succeed
initially and then retries, goes from the status In Progress to the status Stalled, with a
message describing why the command did not succeed.
Cancelled the command failed and, while it was being retried, the user cancelled it
successfully.
Redundant the command had dependencies that were not met, (for example, it may
have depended on a previous command that has been cancelled), and
so the command is now redundant.
Timed Out the command did not manage to start before either its end time was
reached, or the number of retries allowed was exceeded.
For every option, you must select one or more command transactions from the Command
Transactions list before clicking the right mouse button and selecting the option.
Transaction Messages displays the transaction message history for the selected command
within the Transaction Messages form (see Viewing Transaction Messages).
Transaction Details is available to the Administrator only, to assist in detailed investigation. It
displays the details for the selected command within a form.
7:3 12.0
Global User Guide
Monitoring Command Progress
If you select a different command, or select a transaction message from the Transaction
Messages form (described in Viewing Transaction Messages), this form changes
automatically to show the details for the selected command or message.
Flag displays the Command Transaction Flag form, where you can define your own Flag
Text to flag the selected command transaction:
The default Flag Text is ‘Follow Up’. Flagging a command transaction is useful if you want to
find it again later. For example, if the daemon runs overnight, you may want to return to a
command transaction on the following day to check its progress. Checkmark the Display
7:4 12.0
Global User Guide
Monitoring Command Progress
flagged commands only checkbox on the Command Transactions form to display flagged
command transactions only.
Cancel Selected Commands Cancels the selected command(s). You can only
cancel commands that have the status Waiting or
Stalled. After a command is cancelled, the transaction
element relating to that command has its status
changed to Cancelled.
If the form is displayed for several minutes, press Update to update the Command
Transactions list from the transaction database, re-applying the filter criteria.
The form can be used in two different modes. You can choose, by selecting the appropriate
option button, to view all messages as they are recorded during the Progress of a
7:5 12.0
Global User Guide
Monitoring Command Progress
command, which may just be temporary failure conditions, or you can view messages
arising from the Results of a completed command.
You can further filter the messages displayed using the option buttons at the base of the
form.
For example:
If you were claiming a Zone then the Successes record each significant element that
succeeded. (Branches in this case).
Any Branches that could not be claimed (perhaps because they had already been claimed
by another user) would be listed in the Failures list.
Operations give a more detailed breakdown of the command, enabling to progress to be
checked more finely.
The user/location and Database are displayed at the top of the form. The Command text
box displays the selected command and the Message text box displays the final message
associated with this command. You can use the down button to view the transaction
messages for the next command in the Command Transactions list and the up button to
view the transaction messages for the previous command.
Each command may trigger several operations, and each operation may cause several
messages to be produced. The Message List scrollable list displays the Issue Date, Type,
and other information about the messages produced as a result of the original command.
Clicking the right mouse button displays a menu with the options described below.
Update updates the transaction message information displayed.
Command Filter allows sub-filtering of Messages, Successes or Failures that originate
from Commands
Operation Filter allows sub-filtering of Messages, Successes or Failures that originate from
Operations
The Administrator may have previously selected Transaction Details from the right mouse
button menu on the Command Transactions list to display the transaction details within a
form (see Managing Commands and Transactions). If that form is still open, clicking on a
transaction message or a transaction operation in the Transaction Messages form displays
the details for the selected item within the form.
7:6 12.0
Global User Guide
Monitoring Command Progress
The Event Loop is common to all locations. It is the time, ranging from 1 second to 5
minutes (300 seconds), between the execution of each operation arising from a command.
The recommended Event Loop is 5 seconds.
The Timings to Locations panel displays the timing values for commands issued from a
specific Location.
Use the Location list to specify the location for which the timing values will be displayed.
The list shows all the locations to which the current location (the location at which the
Administrator is using this form) has a direct connection, that is, the parent and immediate
children (if any).
The Timeout is the maximum period of time spent trying to send a command.
Note: Using a short timeout value can cause some operations to fail (e.g. Claims and
Flushes).
Retries is the maximum number of times that an attempt is made to send a command.
The Interval is the delay between retries.
Resend is the delay before resending a command that has already been sent. This is a
failsafe.
Press Apply to set the event timings for the selected Location to be the values displayed
currently.
Press Defaults to display the default settings for the selected Location.
Press Current Settings to display the current settings for the selected Location - these
may be different to the default settings.
7:7 12.0
Global User Guide
Monitoring Command Progress
Merge/Purge from the main ADMIN menu bar. The Transaction dB Merge/Purge form is
displayed:
7:8 12.0
Global User Guide
Monitoring Command Progress
Transactions can be purged based on the results of the transaction and the time the
transaction was made.
Use the "Older than" option to specify the number of days; transactions older than this
number will be included for purging. The number of days should be in the range of 1 to 365
days.
From the Purge drop-down menu, choose ALL / SUCCESS / FAILURE. Selecting ALL will
delete all the transactions which are not in progress and older than the specified time.
Selecting SUCCESS or FAILURE purges only Passed or Failed transactions respectively.
Merge Transaction DB will merge the transaction DB of the current location. This will have
no effect unless either the database has been purged or commands have been deleted
interactively.
The Command transactions form is available in other modules, but will not have the Purge
transactions frame.
7:9 12.0
Global User Guide
Monitoring Command Progress
In this case, all successful database updates report ‘no data to send’ since the database
was up to date. This is reflected in the summary, which reports the number of successful
Copies and Updates.
Note: The success for the Global db is also reported as database =0/0.
A scheduled update normally only sends the latest sessions for a database - this is an
Update. However, if the database has been merged or had another non-additive change
(reconfigure, backtrack), then the entire database file must be copied. Database copies are
always executed at the destination (the location to which the file must be copied).
The file is copied from the remote location to a temporary file with the suffix .admnew and
then committed. The database copy cannot be committed in the following circumstances:
• There are users in the database (recorded in the Comms db)
• There are dead users (file is locked) and Overwriting is disabled (see below)
• If the commit fails, the .admnew file will be retained. The next copy attempt will test this
file against the remote original to see whether the remote copy stage must be repeated.
In the case of updates, the number of sessions and pages sent is also reported in the
success for each database as well as cumulated in the update summary. In the case of
copies, the number of pages sent will only be reported if the copy is executed locally.
For DRAFT databases, the number of picture-files sent is also reported.
The update summary also reports on the number of other data files transferred (see also
success for ‘Exchange of other data’).
7:10 12.0
Global User Guide
Monitoring Command Progress
Note: This will always report a success even if there is nothing to transfer or ‘Other data
transfer’ is not set up.
In this case, the databases could not be propagated, since the secondary database had a
higher compaction number than the primary database. This may happen when a remote
merge is executed without stopping scheduled updates. Normally it will be necessary to
recover the database to resolve this error.
Prevention of Reverse propagation may also be reported in the following situation - a
satellite has executed a direct update (UPDATE DIRECT from the command-line) with a
non-neighbour satellite. The next scheduled update with the intermediate location will report
‘Prevented reverse propagation’. In this case, scheduled updates will eventually resolve the
situation.
The following table summarises Failure messages that can be generated for Scheduled
updates. This does not include all possible failures that may be generated from failed file
copies.
7:11 12.0
Global User Guide
Monitoring Command Progress
7:12 12.0
Global User Guide
Monitoring Command Progress
In this example, the database still had readers, so the copy could not be completed. An
additional failure reports that 18 pages have been copied from the remote location. The next
retry validates the .admnew file, but still cannot commit it due to readers. A further retry
validates the .admnew file again and attempts to commit it. In this case there are no
readers, but the file is locked.
7:13 12.0
Global User Guide
Monitoring Command Progress
In this case, the SYNCHRONISE command eventually succeeded, since Overwriting was
enabled.
Note: The ‘Successful file copy’ success reports that nothing has been copied, since the
remote copy stage was executed successfully on an earlier try, when the copy failed.
Detailed failures for file copies can only be reported at the destination. During a scheduled
update, the success of a copy is verified by checking that the compaction number has
changed. If the copy was executed at the location which executes the scheduled update,
then additional failures may show more detail. (Note this is the partner location for a
scheduled update, not the originator!)
7:14 12.0
Global User Guide
Global Daemon Messages
When a project is first made Global, or when a new location is created, the daemon must be
started up at each on-line location as described in Running the Global Daemon. The
daemon should be started up on the workstation that will be connected to the remote
locations.
This chapter explains some of the messages that may be output by the daemon if there is a
problem. The messages, with brief explanations and suggestions about what to do, are
given below.
Message Meaning/action
Wrong number of arguments The start or stop command line argument is missing.
Invalid argument Attempt to use a command line argument other than
start or stop.
Project name should be 3 A project code should be exactly three characters long.
characters long It is case insensitive.
Project environment variable not The environment variable (in the form ABC000) is not
set set. Set the environment variable and then retry.
Project directory not found The environment variable (in the form ABC000) is set
but it does not appear to point to a valid directory.
RPC communication problem You cannot communicate with other locations. There
appears to be a problem with the installation of the
underlying communications software. See AVEVA
support pages http://support.aveva.com.
admind daemon already started The Global daemon is already running on the local
workstation. Only one version of the Global daemon
may be started on a workstation.
Message Meaning/action
Unable to find/open PDMS The daemon has been unable to find and to then open
system database the System database in the project directory. Check
that the environment variable is pointing to the correct
directory and that the directory contains a project.
8:1 12.0
Global User Guide
Global Daemon Messages
Message Meaning/action
Unable to find/open the PDMS The daemon has been unable to find and to then open
Global database the Global database in the project directory. Check that
the environment variable is pointing to the correct
directory and that the directory contains a project. If the
project does not contain the files glbvir.dat and abcglb
(for project ABC), then it is not a Global project.
Unable to find/open the PDMS The daemon has been unable to find and to then open
Comms database the comms database in the project directory. Check
that the environment variable is pointing to the correct
directory and that the directory contains a project.
Unable to find the reference to The STAT element in the System database contains a
the current location reference attribute LOCRF. If the Global project has
been created properly, then the LOCRF attribute will
correctly point to a Location element in the Global
database. This problem could arise if the wrong
System database had been copied manually to a
location.
Unable to find the name of the The STAT element in the System database contains a
current location reference attribute LOCRF. If the Global project has
been created properly, then the LOCRF attribute will
Incorrect System DB
correctly point to a Location element in the Global
database.
Hostname has not been set for The Location element contains an attribute RHOST
this location that does not appear to have been set.
Attempt to run daemon on The Location element contains an attribute RHOST
processor … that does not appear to match the hostname of the
Hostname for this location current workstation.
should be …
Unable to start PDMS database One of the main sub-systems of the Global daemon
thread has not started. Try to restart the daemon; if it
continues to fail then please report the problem to
AVEVA Customer Services.
Unable to start PDMS timer One of the main sub-systems of the Global daemon
thread has not started. Try to restart the daemon; if it
continues to fail then please report the problem to
AVEVA Customer Services.
8:2 12.0
Global User Guide
Global Daemon Messages
about the problem using the options on the Local Daemon Settings form, displayed when
you select Settings>Daemon Settings on the main ADMIN menu bar. If it is necessary for
you to use the form, see the on-line help for more information.
The diagnostics are not available for off-line locations.
8:3 12.0
Global User Guide
Global Daemon Messages
8:4 12.0
Global User Guide
Off-line Locations
9 Off-line Locations
This section describes how to create and install an off-line location, and the tasks that are
required only at off-line locations. The tasks are:
• Transfer from the Hub to the off-line Satellite.
• Transfer from the off-line Satellite to the Hub.
• Removal of old database and Picture files.
The only communication for off-line locations is between the location itself and the Hub.
Transfer is by means of a tape or other media.
Note: Using off-line locations limits the Global functionality which can be used. Updates will
have to be transferred manually, for example, by writing a tape. The Remote
operations are not available for off-line locations.
If using extracts, the entire extract hierarchy must be primary or secondary at the offline
location. You cannot have some extracts primary at the offline location and some at other
locations, since certain operations such as claiming and flushing will fail (See the Running
Global Projects manual for further details). Note also that if you are using Claims and
Flushes, they may fail if you have set a short time-out on commands.
Also, at this release, it is recommended that you should not change a Satellite to be off-line
once it is initialised, and you should not change the primary location of a database from an
off-line location. Any extract structure must be completely at this location (not across
locations).
Note: An off-line location cannot have on-line connections with any other location.
9:1 12.0
Global User Guide
Off-line Locations
Environment variables must be set at both the Hub and the Satellite to point to the Transfer
directory at each location.
Example:
The project code is ABC.
Cambridge is the Hub, with the location identifier CAM.
There are two off-line Satellites:
• Sydney has the location identifier SYD;
• Perth has the location identifier PER.
The transfer directory at the Hub has a subdirectory for each location:
pathname\sydney
pathname\perth
Each subdirectory will have the normal project-related directory structure, abc000, abcmac,
etc.
Note: The transfer directory is used in the same way as the transfer directory for an on-line
location when the location is first generated. You can delete the directories for an on-
line location once the project has been installed there, but you should keep the
directories for the off-line locations, as they will be used for transferring updates.
9:2 12.0
Global User Guide
Off-line Locations
At the Satellite:
The Administrator at the Satellite will make sure that the subdirectories in the Transfer
directory are empty, and then load the media received from Hub and read the contents into
the Transfer directory.
Select Utilities>Offline Transfer, and the Offline Data Transfer form will be displayed.
Set the Transfer Operation gadget to Import Data.
The Project Locations text pane lists the locations available for transfer. At an off-line
location this will only show the Hub.
If the databases in the Transfer directory contain more recent data than the databases in the
base product project directory, then they will be copied over to the base product project
directory.
9:3 12.0
Global User Guide
Off-line Locations
At the Hub:
The Administrator at the Hub will make sure that the subdirectories in the Transfer directory
for the appropriate off-line location are empty, and then load the media received from the
Satellite and read the contents into the Transfer directory.
Select Utilities>Offline Transfer, and the Offline Data Transfer form will be displayed. Set
the Transfer Operation gadget to Import Data, select the location required in the Project
Locations list, and press OK.
If the databases in the Transfer directory contain more recent data than the databases in the
project directory, then they will be copied over to the project directory.
9:4 12.0
Global User Guide
Menu Maps
A Menu Maps
This appendix shows menu maps for the options under the main ADMIN menu bar.
• The Global options, which are additional to those in a standard project, are shown in
bold.
• Options which are only available at the Hub are shown in bold italic.
• Options which are only available for on-line locations are marked with an asterisk *.
Note: Some options will only be available under certain conditions, for example,
Data>Recover Hub will only be available if a change of Hub has failed.
A:1 12.0
Global User Guide
Menu Maps
Names
Descriptions Load Current Config
Resize Admin Elements form Save Current Config
Setup Admin Elements form Reset Config to Defaults
Manage User Config file > Delete YOUR config
Project Information...
Font Families...
Module Definitions...
Replicate > Project data . . .
Expunge > Project structure . . .
Data Access Control Standalone . . .
Initialise Location Satellite . . .
All Users . . .
User process . . .
Claimlist . . .
Picture Files
Database Files
A:2 12.0
Global User Guide
Menu Maps
Merge Changes . . .
Data Change Management >
Backtrack Changes . . .
Inter-DB Macros...
Extract Database Control
Database Allocation > By Database . .
Update . . . By Location . . .
Synchronise . . . Update order . . .
Recover >
Database . . .
Primary Location . . .*
Hub *
*available Only if a Change Primary Location or Change Hub Location operation has failed.
Note: If a Global project is being used to distribute catalogue databases for other projects
to include, the Overwrite DB Users flag should be disabled (see Admnew Files in the
Running Global Projects guide).
A:3 12.0
Global User Guide
Menu Maps
A:4 12.0
Global User Guide
Index
A creation . . . . . . . . . . . . . . . . . . . . . . 3:1
de-allocation . . . . . . . . . . . . . . . . . . 5:7
Admin deleting . . . . . . . . . . . . . . . . . . . . . . 5:9
Elements form . . . . . . . . . . . . . . . . . 4:2 foreign . . . . . . . . . . . . . . . . . . . . . . . 3:8
Admin daemon . . . . . . . . . 2:1, 3:1, 3:5, 4:4 merging sessions . . . . . . . . . . . 3:7, 5:16
diagnostics . . . . . . . . . . . . . . . . . . . . 8:2 non-propagating . . . . . . . . . . . . . 3:8, 5:9
progress messages . . . . . . . . . . . . . 8:2 scratch . . . . . . . . . . . . . . . . . . . . . . . 3:8
stopping . . . . . . . . . . . . . . . . . . . . . 4:11 updates . . . . . . . . . . . . . . . . . . . . . . 3:6
Allocation . . . . . . . . . . . . . . . . 4:8, 4:17, 5:2 De-allocation . . . . . . . . . . . . . . . . . . . . . 5:7
of databases . . . . . . . . . . . . . . . . . . . 3:8 Deleting
Allocation order . . . . . . . . . . . . . . . . . . . . 5:6 Databases . . . . . . . . . . . . . . . . . . . . 5:9
Ancestor (Location) . . . . . . . . . . . . . . . . . 3:3 Locations . . . . . . . . . . . . . . . . . . . . 5:13
Area number . . . . . . . . . . . . . . . . . . . . . . 5:9 Descendant (Location) . . . . . . . . . . . . . . 3:3
DRAFT . . . . . . . . . . . . . . . . . . . . . . . . . . 3:9
C
Child (Location) . . . . . . . . . . . . . . . . . . . . 3:3 E
Command Transactions . . . . . . . . . . . . . 5:6 Environment variables . . . . . . . . . . . . . . 4:7
Commands . . . . . . . . . . . . . . . . . . . . . . . 7:1
managing . . . . . . . . . . . . . . . . . 7:3, 7:6
Communications
F
networks . . . . . . . . . . . . . . . . . . . . . . 3:3 Foreign Databases . . . . . . . . . . . . . . . . . 3:8
D G
Daemon . . . . . . . . . . . . . . . . . . 2:1, 3:1, 3:5 Global . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1
Data Access Control . . . . . . . . . . . . . . . . 5:1 Global Daemon
Data integrity checking . . . . . . . . . . . . . 5:21 running check . . . . . . . . . . . . . . . . 4:14
Data recovery . . . . . . . . . . . . . . . . . . . . . 6:3 service configuration . . . . . . . . . . . 4:13
remote . . . . . . . . . . . . . . . . . . . . . . 5:20 Groups . . . . . . . . . . . . . . . . . . . . . . . . . 5:13
Database . . . . . . . . . . . . . . . . . . . . . . . . . 3:2 root . . . . . . . . . . . . . . . . . . . . . . . . . 5:13
allocation . . . . . .3:1, 3:8, 4:8, 4:17, 5:2
area . . . . . . . . . . . . . . . . . . . . . . . . . 5:9
H
backtracking . . . . . . . . . . . . . . . . . . . 3:7
compaction . . . . . . . . . . . . . . . . . . . . 3:7 Hostname . . . . . . . . . . . . . . . . . . . . . . . . 4:4
Hub P
location . . . . . . . . . . . . . . . . . . . . . . . 4:3
Hub Location Parent
changing . . . . . . . . . . . . . . . . . . . . . 5:11 (Location) . . . . . . . . . . . . . . . . . . 3:3, 4:5
recovering . . . . . . . . . . . . . . . . . . . . 5:12 Pending file . . . . . . . . . . . . . . . . . . . . . . 3:6
Picture files . . . . . . . . . . . . . . . . . . . . 3:9, 5:9
Plot files . . . . . . . . . . . . . . . . . . . . . . . . . 3:9
I Primary Location
Initialising Locations . . . . . . . . . . . . . . . 4:14 recovering . . . . . . . . . . . . . . . . . . . 5:10
Installing Project Project
at Satellite . . . . . . . . . . . . . . . . . . . . . 4:9 making . . . . . . . . . . . . . . . . . . . . . . . 4:1
Integrity checking . . . . . . . . . . . . . . . . . 5:21 Replication . . . . . . . . . . . . . . . . . . . 5:14
Inter-db macros . . . . . . . . . . . . . . . . . . . 6:10 Projects . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
ISODRAFT files . . . . . . . . . . . . . . . . . . . 3:9 Propagation . . . . . . . . . . . . . . . . . . . 3:1, 3:6
Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1 non-propagating files . . . . . . . . . . . . 5:9
remote . . . . . . . . . . . . . . . . . . . . . . 5:17 Propagation order . . . . . . . . . . . . . . . . . 5:6
L R
Location . . . . . . . . . . . . . . . . . . . . . . . . . 3:1 Recovering
code . . . . . . . . . . . . . . . . . . . . . . . . . 4:4 Hub Location . . . . . . . . . . . . . . . . . 5:12
creating . . . . . . . . . . . . . . . . . . . . . . . 4:7 Primary Location . . . . . . . . . . . . . . 5:10
deleting . . . . . . . . . . . . . . . . . . . . . . 5:13 Transaction Database . . . . . . . . . . . 6:5
description . . . . . . . . . . . . . . . . . . . . 4:4 Recovery of data . . . . . . . . . . . . . . . . . . 6:3
Groups . . . . . . . . . . . . . . . . . . 3:4, 5:13 remote . . . . . . . . . . . . . . . . . . . . . . 5:20
id . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:4 Remote operations . . . . . . . . . . . . . . . . 5:14
initialising . . . . . . . . . . . . . . . . . . . . 4:14 Replication . . . . . . . . . . . . . . . . . . . . . . 5:14
name . . . . . . . . . . . . . . . . . . . . . . . . 4:4 Root
off-line . . . . . . . . . . . . . . . . . . . . 3:4, 9:1 of Location Group . . . . . . . . . . . . . 5:13
Primary . . . . . . . . . . . . . . . . . . 3:1, 4:15
Secondary . . . . . . . . . . . . . . . 3:1, 4:15 S
Location Groups
root . . . . . . . . . . . . . . . . . . . . . . . . . 5:13 Satellites . . . . . . . . . . . . . . . . . . . . . . . . . 4:9
Locking . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1 Scratch
remote . . . . . . . . . . . . . . . . . . . . . . 5:17 databases . . . . . . . . . . . . . . . . . . . . 3:8
files . . . . . . . . . . . . . . . . . . . . . . . . . 5:9
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 3:6
M Synchronisation
MDBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1 (see also updates) . . . . . . . . . . . . . . 6:2
Merging/Purging a Transaction Database 7:7 System Database . . . . . . . . . . . . . . . . . . 3:2
Messaging . . . . . . . . . . . . . . . . . . . . . . . . 6:7
Monitoring commands . . . . . . . . . . . . . . . 7:1 T
Transaction
N database . . . . . . . . . . . . . . . . . . . . . 3:6
Networks Event Timings . . . . . . . . . . . . . . . . . 7:6
communications . . . . . . . . . . . . . . . . 3:3 Transaction Messages
Non-propagating files . . . . . . . . . . . 3:8, 5:9 managing . . . . . . . . . . . . . . . . . . 7:3, 7:6
status . . . . . . . . . . . . . . . . . . . . . . . . 7:3
Transfer Directory
O
off-line Locations . . . . . . . . . . . . . . . 9:1
Off-line Locations . . . . . . . . . . . . . . . . . . 9:1 Transfer directory . . . . . . . . . . . . . . . . . . 4:6
U
Update events . . . . . . . . . . . . . . . . 3:7, 4:19
Updates . . . . . . . . . . . . . . . . . . . . . . . . . . 3:6
(see also synchronisation) . . . . . . . . 6:1
unscheduled . . . . . . . . . . . . . . . . . . . 6:1
Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
W
Working files . . . . . . . . . . . . . . . . . . . . . . 5:9