Global

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.
First published September 2007
AVEVA Solutions Ltd, and its subsidiaries
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

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

Overview of Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1

Communications Between Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1

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

12.0

Global User Guide

Foreign Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Working Extracts used as Non-Propagating Databases . . . . . . . . . . . . . . . . . . . . . . . . . . .
Working Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DRAFT Picture and Neutral Format File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compulsory Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other Non-propagating Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transfer of Other Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3:8
3:8
3:9
3:9
3:9
3:9
3:9

Multiwrite Databases in a Global Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:10

Setting up a Global Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1

Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1
Making the Project Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1
Starting Up Global ADMIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:2
Modifying the Hub Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:3
Before you Create Location Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:6
Creating Location Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:7
Notes on Newly Generated Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:9

Installing a New Project at a Satellite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:9

Running the Global Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:9
Location of Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the admind command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Single Project Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multiple Project Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Control the Daemon from the Control Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4:10
4:10
4:11
4:12
4:13

Initialising a New Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:14

Setting Primary Locations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:15
Database Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:17
How Databases are Allocated to Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:18
Allocating New Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:19

Creating Update Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:19

Managing Scheduled Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:21

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:22
Backing Up and Restoring Global Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:22

Hub Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:1

Data Access Control and Stamps in a Global Project . . . . . . . . . . . . . . . . . . . . 5:1
Database Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:2

ii

12.0

Global User Guide

Checking Communications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Allocating a Database to a Location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Checking Database Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
More Notes on Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Allocation Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
De-allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What Happens When Databases are Allocated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5:2
5:2
5:5
5:5
5:6
5:7
5:8

Deleting Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:9

Using Different Database Areas in Global Projects . . . . . . . . . . . . . . . . . . . . . . 5:9
Non-propagating Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:9
Changing the Primary Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:10
Recovering the Primary Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:10

Changing the Hub Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:11

Deleting Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:13
Location Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:13
Replication in a Global Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:14
Remote Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:14
Remote Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote Locking and Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote Data Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote Expunging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote Database Integrity Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5:15
5:17
5:18
5:19
5:21
5:21

Querying Remote Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:22

Administering System Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:25
Verify Daemon Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:25

Local Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1

Locking

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1

Isolation

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1

Unscheduled Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1

Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:2
Updates
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:3

Data Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:3

Recovering Secondary Databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:4
Recovering Primary Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:4
Recovering the Global Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:5

iii

12.0

Global User Guide

Recovering the Transaction Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:5

The Recover Database Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:5

Messaging in a Global Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:7

Administering System Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:8
Repairing the System Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:9

Merging Changes in a Global Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:9

Inter-db Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:10
Database Access Control at Satellites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:10

Monitoring Command Progress. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1

Viewing Command Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1
Managing Commands and Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:3
Viewing Transaction Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:5
Changing Transaction Command Timings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:6
Merging and Purging a Transaction Database . . . . . . . . . . . . . . . . . . . . . . . . . . 7:7
Scheduled Merging and Purging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:7
Merging and Purging from ADMIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:8

Success and Failures from Scheduled Updates . . . . . . . . . . . . . . . . . . . . . . . . . 7:9

Scheduled Updates - Successes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:9
Scheduled Update - Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:11
Failed File Copies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:13

Global Daemon Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:1

Progress Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:2

Off-line Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:1

Creating Off-line Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:1
Transfer Directories for Off-line Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:1
Transferring Updates to Off-line Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:3
Transferring Updates from Off-line Locations . . . . . . . . . . . . . . . . . . . . . . . . . . 9:4

Menu Maps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A:1

iv

12.0

Global User Guide

Introduction to this Manual

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

Who Should Read This Manual

This user guide is written for System Administrators who are responsible for setting up and
managing Global projects. It is assumed that you are already familiar with the normal
administration of non-Global projects, as described in the Administrator User Guide.
The project sites are called Locations. One of the locations, called the Hub, will have
overall responsibility for the administration of the project. The other locations are called
Satellites.
There are two levels of administration required: hub administration and local
administration. Local administration tasks need to be carried out at the hub and the
satellites. This guide is written for administrators at all locations, although the distinctions
between hub and satellite administration are also explained.

1.2

How to Use This Manual

Overview of Global is an overview of the application.
Concepts, describes the basic concepts of using AVEVA Global.
Setting up a Global Project, is a step-by-step description of how to make a Global project,
starting from a standard project.
Hub Administration, describes how to do the tasks that the Administrator at the Hub will
need to carry out once the Global project has been created.
Local Administration, describes how to carry out the tasks that all Administrators will need to
do.

1:1

12.0

Global User Guide

Introduction to this Manual

Monitoring Command Progress, describes how to monitor the progress of Global

commands and, if necessary, cancel commands.
Global Daemon Messages, describes some of the messages that may be output by the
Global daemon if there is a problem with the communications links between Locations.
Off-line Locations, describes how to set up and administer the communications for off-line
Locations.
Menu Maps contains Menu Maps for the GUI, with the options that are specific to Global
Administration shown in italics.

1.3

Other Documentation
You may need to refer to the following documentation:
Global Installation Guide describes how to install the files needed to run Global.
Flexman Installation Guide describes how to install the AVEVA licensing product.
Administrator User Guide describes how to use the standard ADMIN GUI.
Administrator Command Reference Manual describes the commands underlying the
interface.
Running Global Projects gives some additional information about the effective use of
Global.

1:2

12.0

Global User Guide

Overview of Global

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

Communications Between Locations

In Global, inter-location communication is handled by a program, separate from the base
product known as the Global daemon, running at each location.
A daemon is a process that runs on a computer, usually as a background process, without
the need for any direct user interaction, and provides a service to other processes. There
are many programs that are provided by the operating system for managing access to file
systems, printers etc. These programs are typically implemented as daemon processes.
If a communications link is lost, the software engineers at each location will be able to
continue working uninterrupted with the current data at that location. When communications
are restored, the updates will re-start and the location will be updated with the latest
available data.

2:1

12.0

Global User Guide

Overview of Global

2:2

12.0

Global User Guide

Concepts

Concepts
This section describes the basic concepts of setting up a Global project using a small
project as an example.

3.1

What is a Global Project?

A Global project allows base product users in different places, known as Locations, to
access the same project. Each location has its own local copy of the product, and local
copies of project databases. Databases can only be written to at a single location, but the
data is then made available for users at other locations to read. For users at a location to
have write access to a database, the database must be made Primary at the location.
(normal base product access controls also apply.) The read-only copies of the database are
called Secondary databases.
Part of the product is a program called the Global Daemon, which monitors the changes to
all the databases at given intervals, and automatically updates all the databases with the
latest changes.

3.2

How Databases are Handled

Databases (and the Teams that own them) can only be created at the Hub, and all
databases must always exist at the Hub. Ordinary (that is, non-system) databases (and the
Teams that own them) are then allocated to the Satellites where they need to exist. (This
does not apply to all extracts. Working extracts can only be created at Satellites. Ordinary
extracts can either be created at the Hub and then allocated, or the Satellite can request
their creation.)
When the teams and databases have been allocated, the Hub Administrator can make each
database Primary at the location which needs write access.
Each location will have its own MDBs, Users and module definitions, stored in its own
System database and propagated to all other locations - see next section for details. MDBs
and Users can be created and maintained by the System Administrator for the location: this
will either be the local System Administrator or the System Administrator at a remote
location - see next section for details. They are used in the same way as MDBs and users in
standard projects, although users who need write access to a database will have to be
members of the team that owns the database.
Changes are made to databases at their Primary location. The updates are then
propagated to all the other locations to which the database is allocated. As copies of all
System databases exist at all locations, changes to these databases are propagated to
every location.

3:1

12.0

Global User Guide

Concepts

3.3

System and Global Databases

The Hub is the location where the overall project administration takes place. It is the only
location where you can create and modify:

Teams

Databases (except for working extracts, which can be created at Satellites)

Roles (if you are using Data Access Control)

Other Locations and Location Groups

Global projects are set up just like standard projects, by creating the project directory
and its sub-directories, and setting environment variables in the normal way. At this
point, the standard System database stores references to all the Admin elements
(Teams, Users, Databases, MDBs etc.) in the project.
Then you give the command to make the project Global.

Note: The location at which you make the project Global becomes the Hub: this location
can be changed later. Making the project Global splits the standard System database
into a newGlobal Global database, which stores information about Teams,
Databases, Locations and Roles, and a new System database which continues to
store information about all the other Admin elements:

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 Satellites 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

3.4

Networks and Communication Links

Normally, locations will have some form of electronic communications, which could range
from a dial-up modem connected to a telephone system, a dedicated Wide-Area Network,
the Internet or a satellite link. Normally the link should have a relatively high speed and
reliable on-line communication channel with as many satellite locations as possible.
However, line speeds as low as 48K are supported.
The communications network must be a tree structure, which means that there is a unique
path between one location and another. The Hub is the root of the tree. It is possible to have
links between one satellite and another, using Location Groups - in this case there is more
than one path between locations. See Location Groups.
The following diagram shows some of the different configurations possible, when Groups
are not used. For a diagram showing the use of Groups, see Location Groups.

Hub
A

Hub

Satellite

Satellite
B

Satellite

Satellite
C

Satellite
D
Hub

Satellite
E

Satellite

Satellite
Satellite

Satellite

Figure 3:1.

Examples of tree structures for locations

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

3.4.1

Off-line Locations
If there is a communications link between a pair of locations, the locations are referred to as
an on-line. Transfer of data between off-line locations is described in Off-line Locations.
Transfer to and from an off-line location can only be made at the Hub. A tape or other media
will be used to copy the databases from one location to another.

3.4.2

The existence of off-line locations will limit the administration capabilities of the project.

Off-line locations can only be children of the Hub. An on-line satellite cannot have offline connections.

Location Groups
Some network technologies allow three or more locations to be linked together as follows:

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:

Using groups, the following network configurations can be supported.

3:4

12.0

Global User Guide

Concepts

Location AAA is the Parent of BBB, CCC and XXX.

Location XXX is the Parent of YYY and ZZZ.
Location ZZZ is the Parent of QQQ, a Location outside the Group.

3.5

Global Daemons
The Global daemon is supplied with the Global product. There must be one Global daemon
running for each project at an on-line location. It is recommended that the daemon should
be run on a file server.

3.5.1

How the Global Database is Updated

Administrative changes to databases in a Global project (allocation, setting primary
locations, etc.) involve changes to the Global database. Administrative changes can also be
made to a Satellites System database from the primary location for the System database,
which can be the Satellite itself, another Satellite, or the Hub. Whenever changes are made
to the Global or System databases, the updated databases are propagated around the
communications network by the Global daemon.
The Global daemon checks the Global and System databases at intervals to see if there
have been any changes: the changes are not propagated instantaneously. If a Satellites
System database is primary at a remote location, once any changes are completed, they
are propagated automatically from the remote location back to the Satellite.

3:5

12.0

Global User Guide

Concepts

It is important to be aware that:

Some commands cannot be executed until conditions are right (for example, a
command may not be executed while users are still accessing the target database).

Commands executed by the daemon will require a GETWORK command to see the
results, as the daemon is effectively another base product user.

All commands which involve daemon activity will take some time, normally a few
minutes, to execute. If the delay is more than this, and the above two conditions have
been observed, check the transaction database. A few commands use the pending
file. See The Transaction Database and the Pending File for further information.

Another fact that influences what happens when commands are executed via the daemon is
that commands are processed in parallel:

3.5.2

In a standard project, commands are processed one at a time, so that the next
command cannot begin until the previous one has finished. In principle, the state of the
system is therefore always known.

In Global, commands which are given at one location but have an effect at another
location are processed in parallel, and so the next command may be initiated before
the previous one has finished. This mode of operation is called non-blocking, and its
advantage is that it prevents a slow, long-transaction command from blocking the user.

However, there are situations when you are issuing a series of commands, and it is
essential that one command has executed completely before the next one can be
carried out.

You can monitor the progress of commands that operate over Global locations, by
using the Command Transactions form. See Monitoring Command Progress for details.
More information about specific operations is given in the appropriate sections of this
manual.

The Transaction Database and the Pending File

A remote command traversing the Global network may be held up at a particular location
(for example, due to a communications fault). For most commands, the stalled command is
placed in a transaction database at that location. The transaction database records the
state of the command so that it can be processed later. This means that commands are
guaranteed to succeed at some time in the future, but that this time cannot be predicted.
See Monitoring Command Progress for further information about the transaction database,
and how you can monitor the progress of commands.
A small number of commands, known as kernel commands, bypass the transaction
database and are stored in a pending file for later processing. An example is the
ISOLATION command which isolates a location.
Other kernel commands are LOCK and UNLOCK and, in relation to a Satellites transaction
database, the ALLOCATE and CHANGE PRIMARY commands. See Pending File in
Running Global Projects for more information about the pending file.

3.5.3

How Database Updates are Propagated

In a Global project, database changes are propagated from the primary location of the
database to all secondary locations of the database.
Databases are updated session by session; that is, each time someone does a
SAVEWORK the changes they have made are added to the end of the database file as a
new session. Only complete sessions are transferred. This ensures the integrity of the
database, and also avoids transferring large amounts of data across the communications
links (except when databases have been compacted: see the note below).

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

Session 0

Session 0

Session 0

Session 0

Session 1

Session 1

Session 1

Session 1

Session 2

Session 2

Session 2

Session 2

Session 3

Session 3

Session 3

Session 3

Session 4

Session 4

Session 4

Session 4

Session 5

Session 5

Session 5

Location AAA

Location AAA

Hub

Hub

Note: The Global database is automatically propagated, although not instantaneously.

Changes which affect a particular Satellite will cause the Global database to be
propagated automatically to that Satellite. In addition, the Global database is
propagated by Update events. If there are no Global commands, the Global
database will not get propagated.

3.6

What Happens if a Communication Link Fails

If the communications link fails anywhere in the network, the base product users at each
location will be able to carry on working with their existing data. Once the communications
connection is restored, the databases will be automatically brought up to date when the next
update occurs. Alternatively, you can manually request that the databases are updated at
any time the communication link is available.
All updates will be based on the most recent state of the databases, deduced by comparison
of databases. This ensures data integrity, even if previous updates have been lost.

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.

3.7

Database Allocation
Every database must always exist at the Hub. Constructor databases must also exist at all
locations where users need to write to them (the primary location) or read them (secondary
locations).
In addition, constructor databases must exist at all locations in the communications network
between the Hub and any other location at which they are needed (whether for writing or
reading)
The System Administrator at the Hub controls which databases are allocated to each
location. If a database is allocated to a location which is not an immediate neighbour of the
Hub (that is, not a Child of the Hub), the database will automatically be allocated to all the
intermediate locations in the communications network.
System databases at all locations are propagated automatically to all other locations.
Transaction databases are automatically allocated and made primary at the locations to
which they belong. By default, transaction databases are non-propagating databases. If
these databases are required at other locations, they should be allocated there explicitly.

3.8

Non-propagating Files

3.8.1

Foreign Databases
In a Global project, you can include or copy databases from a standard project or another
Global project.
Note: Although standard projects cannot access databases in a Global project, it is
possible to convert these to single-location Global projects without requiring a
special license.
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.2

Working Extracts used as Non-Propagating Databases

You can create non-propagating databases for local use at a Satellite, which are never
propagated. Like all databases in a Global project, they can only be created at the Hub,
where they are flagged as non-propagating. They are then allocated to the primary location
where write access is required. Even though they are not propagated, they must still exist at
all locations in the communications network between the primary location and the Hub.
By default, all transaction databases are treated as non-propagating databases, and are
only allocated at the Hub and the owning location.

3:8

12.0

Global User Guide

Concepts

3.8.3

Working Extracts
Working extracts exist only at the Satellite and are never propagated.

3.8.4

DRAFT Picture and Neutral Format File

You can choose whether DRAFT Picture and Neutral Format files will be propagated. By
default, these files are non-propagating.
In general, it is only necessary to propagate Picture files associated with project-wide
DRAFT overlay sheets.

3.8.5

Compulsory Propagation
The following files are propagated regardless despite whether the Picture/Neutral Format
Files Propagation Check box is ticked or not. This is because it is not possible to regenerate
these where the database is secondary;
Final Designer Drawing
Marine Hull Drawing
Diagram
Stencil
Template
For Final Designer drawing only PDMSDWG files are propagated with the DRAFT
database, other DWG files can be propagated through Transfer of Other Data.

3.8.6

Other Non-propagating Files

ISODRAFT files and external PLOT files will not be propagated between locations. If these
files need to be transmitted, normal file transfer methods must be used. See the next
section for other Data Transfer functionality.
Design Manager files; Comparator databases must be created at the Hub, like any other
databases. They are then allocated to the locations where they are required. They are never
propagated, because the contents are always newly created. You must use other methods
to transfer Design Manager picture files and BRIDGE transfer files, if required. For details of
other file transfer methods, see below.

3.8.7

Transfer of Other Data

Files such as ISODRAFT and external PLOT files are not propagated automatically by the
Global daemon. However, there is a mechanism in the daemon to allow such files to be
transferred to and from neighbouring locations.
The daemon uses environment variables to define import and export directories for other
data files. At a location, there is a single directory to receive data imported from other
locations; and a set of export directories, one per neighbouring location, from which data
can be exported to those locations.
For the current project, the import directory at a location is defined by variable %IMPORT%;
the export directory for neighbouring location ABC is defined by variable %EXP_ABC%, etc.
If these variables are defined at each location, then the daemon will automatically transfer
files in these directories from one Satellite to another during scheduled updates (or when
the UPDATE ALL command is used). Files can only be transferred between neighbouring
locations, and this method cannot be used to send files to/from off-line locations.

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.9

Multiwrite Databases in a Global Project

For information about using multiwrite access to databases (extract databases) in a Global
project, see Running Global Projects.

3:10

12.0

Global User Guide

Setting up a Global Project

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
satellites 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.2

Making the Project Global

To make a standard project into a Global project, you should first enter ADMIN and display
the command window. LOCK the project, then send a message to all users asking them to
leave the current session. After you finish making changes, you should UNLOCK the project
so that users have access again.
When there are no users left actively in the project, enter the following commands:

Lock
make global
unlock
The make global command splits the System database as described in System and Global
Databases. If you list the files in the project directory from the operating system, you will see
a new database named projglb, where proj is the three-character project code.

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.

4.3

Starting Up Global ADMIN

The next step is to exit, and then re-enter ADMIN to make the Global ADMIN GUI available.
You will see a message that the Hub is uninitialised: this is just telling you that setting up the
Hub will be your first task.
The main menu bar is slightly different: it tells you the current location, and it also shows
which location you are currently Administering:

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

Figure 4:1.

The Admin Elements form

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.

4.4

Modifying the Hub Location

On the Admin Elements form, select Locations from the Elements option button. The list
of locations will only show the Hub:
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.
Connection will normally be on-line.
Hostname is the identifier of the machine on which the Global daemon will be running at the
Hub.
This can be any one of three things:

the hostname, which is found by typing hostname in a command window.

the IP address:
Select Control Panel > Network
Select the Protocols tab
Select TCP/IP Protocol
Select Properties to see the IP address.

the fully-qualified domain name e.g. hub.domain.com.

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.

For each database master:

Range Type

Number Range

Global, Normal Extracts

(seen wherever allocated)

1 - 3000

Working Extracts, Location HUB

3001-4000

Working Extracts, Location TWO

4001-5000
(allowing this location 1000 working extracts of the
Master Db

Working Extracts, Location THR

5001-6000

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.
Note: Initialisation of a location initialises the Global daemon at that location.

4.5

Before you Create Location Files

Before you set up a new location:
1. You must set up a transfer directory at the Hub which will contain all the files for
transfer to the new location. The files needed for the location will be copied into this
directory, ready for transferring to the actual location.

4:6

12.0

Global User Guide

Setting up a Global Project

2. You must set an environment variable of the form:

XXX_LOC
where XXX is the project code, in this case ABC, and LOC is the location identifier, in
the following example OXF, which you will specify when you create the location. This
variable must point to the pathname of the transfer directory for the new location.
For example:
If the transfer directory for location OXF is

base product install path\projects\transfer

then the variable ABC_OXF must be set as follows:

set ABC_OXF=base product install path\projects\transfer

4.6

Creating Location Files

The following steps create all the files needed for a new location. During the procedure, if
you confirm that you want all the files copied, all the database files that exist at the Hub will
be copied to the Transfer directory. The files will all be secondary at this stage. The
information supplied on the Create Location form will be stored in the Global database, and
then the Global database itself will be copied into the transfer area. The virgin databases in
the Project directory will also be copied. A transaction database is also created and
allocated to the location.
Click Create on the Location version of the Admin Elements form, and the Create
Location form will be displayed:

The Name appears on the Admin Elements form.

The Location ID is a three-letter code that identifies the location.
The Description is optional.

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 locations 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.

4.6.1

Notes on Newly Generated Locations

When a location has been generated by creating the files in the Transfer directory, it will
appear on the list of locations in the Admin Elements form.
Until it is initialised, the location will not appear in other lists of locations; for example, on the
forms used for allocating databases and setting the primary locations of databases.
If you want to check the status of a location, use the Query>Project>Locations option to
display the List Locations form. Select the location you want in the scrolling list.

4.7

Installing a New Project at a Satellite

You can only start the Global daemon at a new Satellite and use the automatic update
system once the System databases are available at the Satellite. Initially, you must therefore
copy databases to a new Satellite by some other method; for example, FTP or a DVD.
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.

4.8

Running the Global Daemon

The normal way of running the Global daemon is as a background service.
Two services are provided: one for a single project and one for multiple projects.
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

4.8.1

Location of Files
To run the daemon as a service, the project directory and the daemon files must be on a
local drive, since the service cannot map network drives.
A full installation of the base product is not required, but the following list of files must be
available on the local machine preferably in the same folder branch:
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

4.8.2

Using the admind command

The Global daemon is started by using the admind command. For the admind command to
run correctly though, environment variables must be set either in a batch file or manually in
a command line window.
Two sample batch files are supplied in the default install folder; singleds and multids.
However these batch files must also be modified to work with your project.
The following environment variables must set in the supplied batch files or your own batch
file before the daemon can be started using the admind command:

Set PDMSEXE to the folder where Global is installed.

Set PDMSWK to point to c:\temp, or a valid empty folder. This is necessary for
performing a remote Data integrity check.

Set the project variables, for example:

ABC000, ABCISO, ABCMAC, and ABCPIC for AVEVA Plant
ABCDRG,ABCMAR,ABCMAC, ABCDIA, ABCSTE, ABCTPL for AVEVA Marine
ABCDWG for Final Designer.

Make sure that the PDMSEXE folder is included in the PATH variable setting.

Set USERNAME to SYSTEM

Note: The Global daemon is dependant on a valid AVEVA License. For more information
relating to licensing refer to the Flexman 4.1 Installation and Configuration Guide.

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.

Give the command to start the daemon.

4:10

12.0

Global User Guide

Setting up a Global Project

Example:

set PDMSEXE=base product install path

set ABC000=%PDMSEXE%\projects\abc000
set PDMSWK=c:\temp
set SAM000=%PDMSEXE%\project\sam000
set SAMMAC=%PDMSEXE%\project\sammac
set SAMPIC=%PDMSEXE%\project\sampic
set path=C:\AVEVA;%PDMSEXE% (you need this in order for the
base product to contact the daemon)
set USERNAME=SYSTEM
%PDMSEXE%\admind start ABC
When you see the Ready message, the daemon is running.
For more information about the Global daemon, and what to do about possible problems,
see Global Daemon Messages.
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.
It is possible to set up tracing and login when the daemon is started, for details of this refer
to Daemon Diagnostics in Running Global Projects.
If you wish to stop the Global daemon manually, give the following command outside the
base product:
base product install path\admind stop prj
where prj is the project code. For example:
base product install path\admind stop ABC
Although the daemon can be started manually from the command line, there is a
disadvantage is that the daemon will stop when you log out.
The daemon can be run as a background service. This allows the program to persist after a
user logs out; and to start automatically when a machine is restarted. This process is
detailed in the following sections.
When the daemon is run as a service, it must be run on a file server.

4.8.3

Single Project Service

To set up the Global daemon to run as a background service (allowing it to continue to run
when logged out) use the DemonServiceSingle or DemonServiceMulti command in
conjunction with the supplied singleds and multids batch files respectively.
DemonServiceSingle /install /project ABC /location singleds
where the batch file singleds.bat is supplied in the default install folder. This batch file will set
all environment variables required to run the service for the single project ABC. The /
location parameter specifies the file location of the batch file, not the base product location
name.
The sample singleds batch file should be edited so that the environment variables are set as
described in Using the admind command:

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):
base product install path\singleds start ABC
This may show what is causing the daemon to stop, for example incorrect or missing
variables.

4.8.4

Multiple Project Service

To set up a multiple project for a project ABC as a background service,in a command line
window type:
DemonServiceMulti /install /location base product install path\multids
As with the Single Project Service the batch file multids.bat is in the default install folder.
This will set all environment variables required to run the required projects. The /location
parameter specifies the file location of the batch file, not the base product location name.
The sample multids batch file should be edited so that the environment variables are set as
described in Using the admind command:
In order to add projects to, or remove projects from, the service, the service must be
stopped and then restarted with a modified batch file.
The start commands in this batch file to start or stop the daemon use parameters. Do not
replace parameter %1 by an explicit start, since this batch file is also used when stopping
the service.
When using a service which interacts with the desktop (see below), individual daemons can
be started using an iconised window if the /MIN argument is used with the start command.
For example:start Project bas /MIN base product install path\admind.exe %1 sam
service

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.
To remove the service, in a command line window type:
DemonServiceMulti /remove

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.
If the installation is unsuccessful, remove the service and install it again.

4.8.5

Control the Daemon from the Control Panel

Once the a daemon has been set up as a service as described in Single Project Service or
Multiple Project Service, it is possible to start and stop the Global daemon service from the
Windows Control Panel. It is also possible to set the daemon to automatically restart when
the PC is rebooted.
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 rebooted.

Set the Startup Type as follows:

Automatic will start the service on boot-up.
Manual means that you will have to start the service by pressing Start on the Services form.
Disabled means just that.
Allow Service to Interact with Desktop means that a window will be opened for each
daemon: you may find this useful when you are setting up a project or tracking any
communication problems.
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.9

Initialising a New Location

Login to the Satellite, and start up ADMIN.
Give the command:

initialise
or select Project>Initialise Location from the main ADMIN menu bar.

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.

or select Query>List>Locations from the main ADMIN menu.

Now exit from ADMIN and re-enter it.
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.
When the Satellite is initialised:

4.10

The Satellite Administrator can start to create local Admin elements in the usual way.

The System database is propagated from its primary location to all other locations
automatically. Subsequently, any changes that an Administrator makes to the System
database will also be propagated to all other locations automatically. So if a Satellites
System database is primary at a remote location (not at the Satellite itself), once any
changes are completed by a remote Administrator, they will be propagated
automatically from the remote location back to the Satellite, and to all other locations.

The Hub Administrator can now make databases primary at the Satellite. See
Changing the Primary Location.

An Administrator, either at the Hub or at the Satellite, needs to set up Update events,
which control when the daemons look for databases that need updating. See Creating
Update Events.
If you look at the Admin Elements forms for the Satellite, you will notice that the
buttons at the bottom of the Teams and Databases versions are inactive: these tasks
cannot be carried out at a Satellite.

Setting Primary Locations

When a location is generated, the locations transaction database is allocated and made
primary at the location automatically. All other databases at the Hub can be transferred to
the new location, where they will be secondary at first. This section describes how to make
a database primary at a location.
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.11

Database Allocation
The following example illustrates how databases need to be allocated in a small project with
three locations:
comms link
Location A (HUB)

comms link
Location B

Location C

In terms of parent and child locations:

A is the parent of B

B is the child of A and the parent of C

C is the child of B

There are five databases:

A Pipework Catalogue, CATA/PIPE.

A Steelwork Catalogue, CATA/STEEL.

A Pipework Design Database, PIPE/PIPE.

A Steelwork Design Database, STEEL/STEEL.

A Drawing Database, DRAFT/DRAFT

Catalogue creation and Pipework design are carried out at Location A, and so the
Catalogue databases and the Pipework Design database must be primary at Location A.
Steelwork design is carried out at Location B, and so the Steelwork Design database must
be primary at Location B. Users at Location B need read access to the Steelwork Catalogue,
so this must exist at Location B as a secondary database.
Drawing production is carried out at Location C. Users at Location C need to have read
access to the Design databases, and write access to the Drawing database, and so the
Drawing database must be primary at Location C.

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.

comms link
Location A (HUB)

+
+
+
-

Location B

CATA/PIPE
CATA/STEEL
PIPE/PIPE
STEEL/STEEL
DRAFT/DRAFT
ISOS/ISOS

Figure 4:2.

comms link

+
+

Location C

CATA/PIPE
CATA/STEEL
PIPE/PIPE
STEEL/STEEL
DRAFT/DRAFT
ISOS/ISOS

CATA/PIPE
CATA/STEEL
PIPE/PIPE
STEEL/STEEL
DRAFT/DRAFT

This is the allocation which we want to achieve.

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.

4.11.1

How Databases are Allocated to Location

If you are creating a location which does not have a direct link to the Hub, and, when
prompted, you confirm that you want all the files copied:

All databases that exist at the Hub will be copied to the new location.

Any databases that do not already exist at the parent of the new location will be copied
to the parent.

See the figures below for an example.

comms

comms

Location A

+
+
+
+
+

CATA/PIPE
CATA/STEEL
PIPE/PIPE
STEEL/STEEL
DRAFT/DRAFT
ISOS/ISOS

Figure 4:3.

Location B

CATA/PIPE
CATA/STEEL
PIPE/PIPE
STEEL/STEEL

Location C

Location C is about
to be created

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

comms link
Location A (HUB)

+
+
+
+
+

CATA/PIPE
CATA/STEEL
PIPE/PIPE
STEEL/STEEL
DRAFT/DRAFT
ISOS/ISOS

Figure 4:4.

comms link
Location B

+
-

CATA/PIPE
CATA/STEEL
PIPE/PIPE
STEEL/STEEL
DRAFT/DRAFT
ISOS/ISOS

Location A (HUB)

CATA/PIPE
CATA/STEEL
PIPE/PIPE
STEEL/STEEL
DRAFT/DRAFT
ISOS/ISOS

Figure 4:5.

CATA/PIPE
CATA/STEEL
PIPE/PIPE
STEEL/STEEL
DRAFT/DRAFT
ISOS/ISOS

This diagram shows the databases at all three locations just after Location C has been
created.

comms link

+
+
+
-

Location C

comms link
Location B

+
-

CATA/PIPE
CATA/STEEL
PIPE/PIPE
STEEL/STEEL
DRAFT/DRAFT
ISOS/ISOS

Location C

CATA/PIPE
CATA/STEEL
PIPE/PIPE
STEEL/STEEL
DRAFT/DRAFT

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.11.2

Allocating New Databases

Once the Global project is set up, you can allocate any new databases required. For
information about allocating databases in a Global project, see Database Allocation.

4.12

Creating Update Events

For automatic updates to take place, you must create an Update event between pairs of
locations. The locations can have a parent-child relationship, or they can both be members
of the same group. You should only create the Update event at one of the locations in the
pair.
When you consider the timing of Update events, it is better not to have a location taking part
in two events at the same time. For example, if there is a chain of locations AAA - BBB CCC, and you wanted hourly updates, you could create an Update event between AAA and
BBB on the hour, and an Update event between BBB and CCC on the half-hour.

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.

4.12.1

Managing Scheduled Updates

A scheduled update between two locations exchanges updates for all databases allocated
to those locations. It is not necessary to have separate scheduled updates at both locations.
You can use single update timer to control several updates - for example at 10:00, 12:00,
15:00 and 23:00 on Mon, Tues and Fri only.
Where you are using more than one update timer you should schedule them to start at
different times to avoid contention on the Global database.
For example, if two updates to different satellites were both required at about 12:00, one
should be started at say 12:02.
At Global 2.4, the scheduled update sends the update command to the partner location to
be executed there. This enables the update to be reported at both locations. At the
originator (ABC), the scheduled update is reported under user TIMEDUPDATES/ABC. At
the destination, the scheduled update is reported under REMOTEDAEMON/ABC (and
hence may be difficult to distinguish from other remote commands).
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.14

Backing Up and Restoring Global Projects

Backing up projects is good practice in any environment: you should ensure that all files at
all locations are backed up regularly.
If you need to restore a Global project, extra attention must be given to any restoring
process that is carried out.

You may be able to restore project databases by using the Recover option. This may
minimise work loss.

You should use the backups for a location only for that location, if possible. In some
cases your only option may be to use backups from other locations. If so, be aware of
the implications it could have on the amount of work lost.

You may need to re-create the transaction databases at locations, using the RENEW
command. For information about this command and others, refer to the Administrator
Command Reference Manual. (If the transaction database file has been deleted, it will
be re-created automatically when the daemon is started.)
Remember the Global database at the Hub is the master Global database. Back this up
before you carry out any major Global administration work.

4:22

12.0

Global User Guide

Hub Administration

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:

5.1

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.

Data Access Control and Stamps in a Global Project

Data Access Control (DAC) and stamps are described in the Administrator User Guide.
There are a few points to note if you are using DAC and stamps in a Global project.

ROLE elements can only be created at the Hub of a Global project: the other DAC
elements (Scopes, Access Control Rights, etc.) are created locally. They are not
propagated from the Hub.

The Hub Administrator is responsible for switching Data Access Control on and off for
the whole project. You should ensure that there are no General users in the project at
any location before you switch DAC on.

STAMP elements can only be created at the Hub of a Global project. It is therefore
recommended that any satellite primary databases have been synchronised with the
Hub before a Stamp is applied.

Note: Remote database queries (see Querying Remote Databases) can be used to verify
whether databases are up-to-date.
Note: Refer to Database Access Control at Satellites for further detail about satellite DAC
administration.

5:1

12.0

Global User Guide

Hub Administration

5.2

Database Allocation
When you first create a location, you can specify whether all or none of the databases will
be allocated to it. Once the location has been set up and initialised, as described in Setting
up a Global Project, the Hub Administrator can change the databases allocated to it.
You may well not need all the databases copied to the transfer directory when the location
was generated: once the location is initialised, you can de-allocate databases which are not
needed. Any databases created after the location has been generated (by pressing Apply
on the Create Location form) will need to be explicitly allocated to the locations where they
are needed.
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.1

Checking Communications
Before allocating databases, ensure that both daemons are running by selecting
Query>Global States>Communications or by issuing a Ping command. The Test Project
Communications form will be displayed. Select the remote location from the list, and press
Apply. (Note: you can also select your current location, as a preliminary check on your own
daemon.)
The form will display a message giving the time taken to contact the remote location if
successful, or telling you that there is a communication failure, in which case, one or both of
the daemons should be re-started.
If the communications failure persists, use the operating system Ping command or tracer to
ensure that the two locations can see each other.

5.2.2

Allocating a Database to a Location

When a database is allocated to a location, a copy of the Hub version of the database will be
sent to the location. This is not necessarily the most up-to-date version of the database. The
database will automatically be allocated to all the intermediate locations between the Hub
and its most remote location, if it is not already present at the intermediate locations.
There are two options under Data>Database Allocation which allow you to change the
allocation of databases. The options are By Database and By Location. The forms are
similar, except in the way the information is organised.
The Database Allocation (By Database) form is displayed when you select By Database.

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 a Foreign database (propagation of Foreign databases is under the control

of the Foreign project)

means Secondary at the current location

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.
Use the arrow buttons to change the allocation.
The Database Allocation (By Location) form is displayed when you select By Location.

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 deallocated. 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

5.2.3

If the Keep MDBs while de-allocating DBs option is set, then the database is deallocated 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.

Checking Database Allocation

After every allocation operation, you should GETWORK and then check to see if the
databases have been allocated successfully (as described in the next section). Remember
that this will take time: it is not instantaneous. See Global Daemons for more information
about how the Global daemon works.
When databases have been successfully allocated to a location, other tasks can be carried
out. For example, the Hub Administrator can make the database primary at the location, and
the Satellite Administrator can add the database to MDBs.

5.2.4

More Notes on Allocation

Several databases can be allocated in the same operation using the Allocate forms.
However, it is advisable to use a macro for long lists of database allocations; for example,
when a project is first set up. See the ALLOCATE command in the Administrator Command
Reference Manual for details.
You should check that the allocation has completed successfully. If you select DB & Extracts
from the Admin Elements form, you will see a list of all the allocated databases.
Alternatively, you can check that the allocation has completed successfully from the
command line as described below, by listing the elements under the DBALL member (the
allocation list) of the LOC (location) element at both the Hub and the Satellite.
A GETWORK must be done before listing the DBALL element, even at the Hub, as the
Global daemon must write the updated DBALL element to the Global database, and the
Global daemon is another ADMIN user.
For example, at location Cambridge:

getwork
/Oxford
1

(go to the DBALL element, which is the first element in the member list)

q mem
Alternatively you can query the DBLC attribute of the Database.
The allocation process may take some time if there is a slow link between Hub and Satellite,
if databases sizes are large, or if the daemon is busy with other operations (such as
updates).
If the newly-allocated databases do not appear in the allocation list, wait a few minutes,
GETWORK and repeat the Query. Allocation is successful when the DBALL list contains all
the databases allocated.
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

Utilities>Transactions to display the Command Transactions form) at either of the

locations affected by the allocation.

5.2.5

Allocation Order
The order in which databases are allocated to a location is important, because it controls the
order in which databases are updated, so that, for example, Catalogue databases are
propagated before Design databases which may refer to changes in the Catalogues.
The Update Order form is displayed when you select Data>Database Allocation>Update
order on the main ADMIN menu bar. The order of the databases in the list is the order in
which they will be updated.

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 Satellites 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.2.7

What Happens When Databases are Allocated

When a database is allocated to a location, there will be a delay before the database
appears at the Satellite. This is because the mechanism used to ensure consistency is as
follows:
When a database is allocated, it is immediately copied to the target location and to any
intermediate locations that do not already have it. When the database arrives, the target
location sends a message back to the Hub, which updates the Global database by adding
the database to the database lists for the locations involved. The Global database is then
sent to the target location: when it arrives, the database is available for use.
When a database is de-allocated, it is removed from the allocation list of the location and
its descendants in the Global database. The Global database is then sent to the location.
When it arrives, the database is deleted (when there are no readers) and all reference to it is
automatically removed from any MDBs in the System database. The Global database is
also sent to any descendants of the location, which removes references to the database at
the descendant locations.

5:8

12.0

Global User Guide

Hub Administration

5.3

Deleting Databases
Databases can only be deleted at the Hub. Before you delete a database, you must change
the primary location to the Hub (or elsewhere) and de-allocate the database from all
Satellites. The procedure for deleting a database is shown in the following diagram:

5.4

Using Different Database Areas in Global Projects

You can use different areas for databases in Global projects in that same way as standard
projects. You must ensure that the environment variable for a databases area must be set
at all the locations to which it is allocated, otherwise the database cannot be propagated
correctly.

5.5

Non-propagating Files
The Propagate Database check box on the Create/Modify Database form defines whether
or not the database will be distributed, and, for a DRAFT database, whether the associated
Picture and Neutral Format files will be distributed.
Non-propagating databases can be used for local working files. Like any other databases in
a Global project, non-propagating databases can only be created at the Hub. Even though
they are not propagated, the databases must still exist at all locations in the chain between
their primary location and the Hub.

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.

5.6

Changing the Primary Location

A constructor database can only be modified by users at its primary location. You can
administer a System database for another location from your own location, provided that the
database is primary at your administering location. If this is not the case, you need to
change the databases primary location to your own location before you can administer it.
You must be at the Hub in order to change the primary location.
To make a database primary at a location, from the Hub, select Databases from the
Elements option button on the Admin Elements form, and press Modify. The Create/
Modify Database form will be displayed. Press the gadget at the left of the Primary Loc.
text box, and the Primary Location form will be displayed.

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.6.1

Recovering the Primary Location

This option can only be used if a change of primary location has failed: it cannot be used to
reverse a successful change. It is only available at the Hub.
The Recover Primary Location form is displayed when you select Data>Recover>
Database>Primary Location on the main ADMIN menu bar.

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).
Recovery of the primary location is normally done automatically if a change operation
applied to a primary location Db fails - check the progress of the command in the transaction
database. An explicit recover operation applied to a primary location Db should only be
used as a last resort. It is normally only required when daemons are down or for offline
locations. It is also required if a create extract operation fails before it has issued
ALLOCATE commands. (See also the Administrator Command Reference Manual
(CHANGE, RECOVER, CREATE EXTRACT and ALLOCATE commands)).

5.7

Changing the Hub Location

You may sometimes need to change the Hub to a different location. The old Hub will
become a Satellite. The Global database will be copied from the old Hub (where it will
become a secondary database) to the new Hub (where it will become a primary database).
Before changing a Hub location a suitable license should be in place on the new project
Hub.
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.

5.8

Deleting Locations
Locations can only be deleted if they have no allocated databases. To delete a location, you
must:

Make the location self-administered (or administered by the Hub).

De-allocate all databases.

De-allocate the transaction database.

Delete it.

The Administrators at the parent and children of the deleted location should then delete any
Update events which refer to the deleted location. The System database for this location
should also be deleted from other Satellites.

5.9

Location Groups
Location groups consist of several locations which all have direct communication links with
each other. This means that there will be communication links within a group which do not
correspond with parent-child relationships. In the following diagram, the dotted lines show
these links.

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.

5.10

Replication in a Global Project

The options under Project>Replicate on the main ADMIN menu allow you to replicate a
Global project in various ways:
To replicate the whole project, including all data, create the new project directory and set
the environment variables pointing to it. Select Project>Replicate>Project Data, and the
Replicate Project form will be displayed. Enter the code for the new project in the text box.
Note: This process may take some time.
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.11

Project>Replicate>Satellite Structure, used at a Satellite in a Global project,

replicates the project as represented in the local System database. That is, the local
information about Users, MDBs and Communication Events will be stored, but not the
elements which can only be created and deleted at the Hub.

Remote Operations
The options under Remote on the main ADMIN menu enable a System Administrator at the
Hub or a Satellite to carry out administrative functions for constructor databases at Satellite
locations. The constructor database for an administered location must be Primary at the
administered location. The ADMIN daemons must be running.
From the ADMIN menu bar, set the Administering option gadget to the location where you
want to administer databases, then select the appropriate Remote option. The options are
as follows:

Remote Change Management

Locking and Isolation

Synchronisation

Data Recovery

Recover Database

Remote Expunge

Integrity Checker

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.

5.11.1

Remote Change Management

Selecting Remote>Remote Change Management>Merge Changes displays the Remote
Merge Changes form.
Each time a user does a SAVEWORK or module switch, a new session is created for that
user for each modified database. To save disk space, you can use the Remote Merge
Changes form to merge database sessions for a remote location.

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.
Note: Database Management
It is important for a System Administrator to consider merging (compressing)
databases. Each organisation will have different working practices but may wish to
consider merging databases on a daily basis.
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

5.11.2

Remote Locking and Isolation

You can Query the Lock and Isolation states of all on-line locations by selecting
Query>Global States>Locking & Isolation. The Query Location Lock & Isolation form
is displayed.

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.11.3

Remote Synchronisation
Selecting Remote>Synchronisation displays the Remote Synchronise Secondary
Databases form. You use the Synchronise Secondary Databases of option button on this
form to select the location where the secondary databases are to be synchronised. The rest
of the form is similar to the Synchronise Secondary Databases form which you use to
synchronise databases at the current location. For more information, see Synchronisation.

5:18

12.0

Global User Guide

Hub Administration

5.11.4

Remote Data Recovery

Select Remote> Recover Database to display the Remote Recover Database form.
The Remote Data Recovery form is similar to the Recover Databases form which is used
primarily to recover remote databases from current location. For more information see Data
Recovery.
The Remote Data Recovery form allows a user to recover a remote database using
another remote database as the source.

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.

Primary Location

If Recover From is set to Primary Location then a Primary

Location database will be used as the source when
recovering a specified database. The specific database can
be selected from a list of databases.

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

5.11.5

Remote Expunging
From time to time a user may exit abnormally, for example if there is machine failure or if a
system fault occurs. An abnormal exit may leave phantom users and/or claimed elements.
Selecting Remote> Remote Expunge displays the Remote Expunge form, which you can
use to expunge database claims and/or users at a remote location.

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.11.6

Remote Database Integrity Check

You can use DICE, the base product Data Integrity Checker, to check the integrity of Global
databases remotely. It is important to identify corrupt databases quickly, as you do not want
to propagate them.
DICE can be carried out from any location, not just from the Hub or an administering
Satellite.
Selecting Remote> Integrity Checker displays the Remote Database Integrity Check
form, which you can use to check the integrity of all or selected databases at a remote
location.

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.
Note: Remote Integrity checking cannot be used on Extract databases.

5.12

Querying Remote Databases

The Remote File Details and Remote Last Session form can be invoked in two ways:

5:22

12.0

Global User Guide

Hub Administration

Either from Admin Main Query menu bar: Query>Project>Remote FiledetailsRemote 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.13

Administering System Databases

A System Administrator at any location can administer the System database for a Satellite
location, provided that the Satellites System database is primary at the administering
location. The administering location can be the Hub or a Satellite location. If necessary, you
can change the location of a System database to make it primary at the administering
location: 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.
For information about the commands that are available when you administer the System
database for a Satellite, see Local Administration.

5.14

Verify Daemon Version

The version of Global in use at a remote location may be queried by:

Q REMOTE <location> BANNER

This will return the Banner for the daemon at the remote location, for example:

AVEVA Global Mk12.0.SP4.0 (9.1) (WINDOWS-NT 5.1) (Mar

5:25

6 2009)

12.0

Global User Guide

Hub Administration

5:26

12.0

Global User Guide

Local Administration

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.3

Unscheduled Updates
If communication links have been broken for some time, databases may have become very
out-of-date. Rather than waiting for the next automatic updates to occur, you can update
locations immediately.
There are two options:

Synchronisation, which updates the secondary databases at the current location. This
is a one-way process.

Updating, which updates the secondary databases at the current location, and also
transmits the updates from the primary databases at the current location to another
location: a two-way operation.
These options are not available at off-line locations.

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.4

Data Recovery
If a database has been corrupted, you can recover the data by transferring a complete
database from another location. You can specify a neighbouring location from which the
data is to be recovered.

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.1

Recovering Secondary Databases

Recover secondary databases from the neighbouring location that is the most up-to-date.
This will usually be the primary database. For example, in the following diagram, if Database
1 is corrupt at Sat 1, recover from the Hub.

6.4.2

Location of Corrupt DB

Corrupt DB

Recover Corrupt DB From

Hub

3, 4, 5

Sat 1, Sat 2, Sat 3 respectively

Sat 1

1+2,4,5

Hub, Sat 2, Sat 3 respectively

Sat 2

1+2,3,5

Hub, Sat 1, Sat 3 respectively

Sat 3

1+2,3,4

Hub, Sat 1, Sat2 respectively

Recovering Primary Databases

You can recover primary databases, but because the primary database is the most up-todate version of that database in the project, there is inevitably going to be some work loss.
Therefore, recovery from back-ups is recommended for primary databases.
To minimise work loss:

6:4

12.0

Global User Guide

Local Administration

6.4.3

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.)

Recovering the Global Database

If for any reason the Global database at a Satellite becomes out of date, it can be
recovered.
Try running the RECOVER GLOBAL AT <loc> or RECOVER GLOBAL TO ALLlocations
commands, provided that the Global network has not been changed. (It will still be
necessary for users (including the Administrator) to leave PDMS at the Satellite.)
If this is not successful then the following procedure should be followed but only if the above
commands are not successful:
1. Stop the Global daemon at the Hub and at the Satellite location.
2. Inform all users, including the Administrator, at both the Satellite and the Hub to save
work and exit their sessions.
3. Physically copy the Global database (e.g. abcglb) from the Hub to the Satellite.
4. Restart the daemons and allow users to start work again.

6.4.4

Recovering the Transaction Database

The transaction database is a non-propagating database. If the transaction database
becomes corrupt, the simplest recovery procedure is as follows:
1. Stop the daemon.
2. Reconfigure from the transaction database to files (if required).
3. Renew the transaction database by one of the methods described in Renewing the
Transaction Database in Running Global Projects, e.g.

Renew delete Transaction /ABC [for location ABC]

4. Start the daemon. This will create a new transaction database from its definition in the
Global database.
5. If required, stop the daemon and reconfigure from files to the transaction database.
The daemon should then be restarted.
Note: Renew without reconfiguration will remove any running commands.

6.4.5

The Recover Database Form

Select Data>Recover>Database on the main ADMIN menu bar to display the Recover
Database to Location form.

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:
Primary Location

If Recover To is set to Primary Location then a Primary

Location database will be overwritten with a specified current
location database. The specific database can be selected from
a list of databases.

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.

All Locations

If Recover To is set to All Locations then the specified

database of each location will be overwritten with the database
of the Primary Location.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.5

Messaging in a Global Project

Utilities>Send Message displays the Send Message form, which allows you to write and
address a message to another user.

6:7

12.0

Global User Guide

Local Administration

The Recipients option button can be set to the following:

Teams

The Teams will be shown in the top window

Users

The Users will be shown in the top window

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.

Type the message, of up to 80 characters, into the Message text box.

6.6

Administering System Databases

You can administer the System database for a Satellite location from the Satellite location
itself, from another Satellite location, or from the Hub, provided that the System database is
primary at your administering location:

If the System database is primary at your location, you can give most ADMIN
commands.

If the System database is not primary at your location, then it is opened as read-only.
You can Query the database but not make any changes to it.

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.

6.6.1

Repairing the System Database

Automatically, on GETWORK or on a module switch into ADMIN a check is done to check if
the System database needs a Repair to remove deleted Global elements including deleted
databases. If a Repair is necessary then a prompt is displayed for the Repair can be done
immediately of later on request using Utilities>System DB Repair .
Note: You will not be prompted to carry out a Repair as a result of the system finding deallocated 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.

6.7

Merging Changes in a Global Project

Databases can only be merged at their primary locations.
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.8

Inter-db Macros
Inter-db macros will be propagated to the locations where they are required. At any location,
macros may exist for databases which are not primary. In this case, these macros will be
ignored and they will not be presented to the users or System Administrators.
Within a Global environment, inter-db macros may need propagating to various locations. In
order for inter-db macros to be propagated to a location:

6.9

The macro directory (for example, abcmac) must exist at all locations where macros
will be created.

The project variable for the macro directory (for example, ABCMAC) must be set for the
process running the daemons.

Database Access Control at Satellites

ACRs and SCOPEs are stored in the System database. In a Global project ROLEs are
stored in the Global database. ACRs contain a reference (ROLEREF attribute) to the ROLE.
This can cause problems at satellites in a Global project if ROLEs are updated at the Hub by
deleting and re-creating the ROLE with the same name but a different reference. This would
require ACRs to be updated at each satellite to use the new ROLE element.
The following alternative options may be used to resolve this problem:
1. Modify the ROLE rather than delete/re-create it. (The member PEROPs can be deleted
and created);
2. Create the new ROLE with the same REF as the old ROLE;
3. Before deleting ROLEs, use OUTPUT functionality at each satellite to create suitable
update macros for the ACRs. These macros will reference the ROLEs by name and
can be run at each satellite to update the ROLEREF attributes after the new ROLEs
have been created.

6:10

12.0

Global User Guide

Monitoring Command Progress

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.

7.1

Viewing Command Transactions

The Command Transactions form can be used to view a list of the current transactions for
the Global commands that have been issued.
This form can be launched from the DESIGN, DRAFT or ADMIN modules via the menu bar
Utilities>Transactions.
When viewing this form in the Admin module an additional tab will be available Purge/
Merge transaction DB for more information refer to Merging and Purging from ADMIN, this
tab will not appear when viewing this form from Design.

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 users 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:
Waiting

the command is waiting to be executed.

Stalled

the command cannot be executed currently.

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.

7.2

Complete

the command has been executed successfully.

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.

Managing Commands and Transactions

When the cursor is in the Command Transactions list, clicking the right mouse button
displays menu options that you can use to manage commands or transaction messages:

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.
Clear Flag

Clears the flag

transactions.

from

the

selected

command

Delete Selected

Deletes the transaction for the selected command

(the record of the command) from the transaction
database. You can only delete transactions for
commands that have the status Complete, Cancelled,
Redundant or Timed Out.

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.

Navigate on Selection

Allows navigation to transaction dB elements to aid

problem analysis (available in ADMIN only).

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.

7.3

Select All

Selects all transactions in the Command Transactions

list.

Clear Selection

Clears all selected transactions in the Command

Transactions list.

Viewing Transaction Messages

To view all transaction messages for a specific command, select the command in the
Command Transactions list, then click the right mouse button and select Transaction
Messages. The Transaction Messages form is displayed, showing all the transaction
messages for the command, from when the command was issued until it was completed:

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.4

Changing Transaction Command Timings

In a Global project only, the Administrator at each location can override various default
values that affect the processing of transaction commands. For example, the Administrator
can change the maximum length of time spent trying to send a command.
To change these default values, from the main ADMIN menu bar, select
Settings>Transaction Timings to display the Transaction Command Timings 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.5

Merging and Purging a Transaction Database

Merging/purging a transaction database reduces and optimises the size of the database by
deleting old command data and removing "dead" space from it.
You can arrange to do this automatically, or you can do it manually from ADMIN.

7.5.1

Scheduled Merging and Purging

To set whether or not the transaction database is to be merged or purged automatically, and
if it is, to set the frequency and scope of the operation, select Settings>Transaction dB

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:

To set the transaction database to be merged/purged automatically, select Automatic

Merging and Purging of the Transaction Database. If this is set to On (the checkbox is
ticked), the rest of the options of the form become available.
Frequency of Automatic Merge/Purge accepts a text entry that controls the frequency at
which the merge/purge will take place. This may be daily, hourly, weekly, monthly, or a
combination. The value entered consists of five fields 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.
Purge Successful Commands (from Transaction dB) older than [n] days, if selected,
will result in all records of commands completed successfully that are older than the number
of days [n] entered in the text box. If "0" is entered, then all successful commands will be
purged.
Purge Failed Commands (from Transaction dB) older than [n] days, if selected, will
result in all records of commands not completed successfully that are older than the number
of days[n] entered in the text box. If "0" is entered, then all failed commands will be purged.
Press Apply to apply the selected settings to the automatic transaction dB merge/purge
facility.
Press Defaults to set the form to the default settings of the automatic transaction dB merge/
purge facility.
Press Current Settings to set the form to the current settings of the automatic transaction
dB merge/purge facility. These will be the last applied settings, or the default settings if no
change to the defaults have ever been applied.

7.5.2

Merging and Purging from ADMIN

Databases can be merged using the Admin module. From the menu bar select
Utilities>Transactions to open the Command Transactions form. When the form is visible
click the Purge/Merge transactions DB tab.

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.
Note: The daemon must be stopped before a merge can be achieved.

7.6

Success and Failures from Scheduled Updates

The scheduled update is a complex operation so it is not always possible for full detail to be
reported for database file copies. The sections below give several examples of what you
can expect to see after various successful and unsuccessful scheduled updates.

7.6.1

Scheduled Updates - Successes

A successful scheduled update will normally report two messages:

7:9

12.0

Global User Guide

Monitoring Command Progress

Each successful update also generates a success:

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.

7.6.2

Scheduled Update - Failures

Generally a scheduled update will always succeed with a number of database failures

Failure messages will contain detailed reasons:

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

Error No

Symptom

Reason

Scheduled update was suppressed

Attribute LNOUPD set TRUE on

LCOMD to disable scheduled update

Remote location CAM is unavailable Daemon for CAM is not available;

Update will not report results to this failure cannot be reported at CAM CAM
usually due to location unavailable

612

Prevented reverse copying

Secondary location has a higher

compaction number than the primary
location.
Database
may
need
recovering

611

Prevented reverse update

Secondary location has a higher

session number than the primary
location.
Database
may
need
recovering

613

Unable to check update direction - The Global database is in use. This is

update skipped
normally temporary, due to another
command.

610

Update skipped - cannot get local The specified database is in use at the
details for <database>
current location. This is normally
temporary, due to another command
using the database.

610

Update skipped - cannot get remote The specified database is in use at the
details for <database>
remote location. This is normally
temporary.

610

Update skipped - cannot get local/ In the case of system databases, if one
remote details for CAM system DB
system db is in use, then the update
will fail for any system db (they all have
the same DB number)

Failed database copy - file may be Unspecified COPY failure - compaction

in use at HUB
numbers are still out of step. If the copy
destination was the update location,
then additional failures will give further
detail.

619

Cannot verify success - may be Unspecified COPY failure - compaction

failed COPY
numbers are still out of step. No further
detail is available.

Missing remote/local file. Prevented System databases only. A system

reverse propagation.
database file is missing at the specified
location. This may need to be
recovered.

615

Update failure - possibly database A database error was encountered

error
during the update. Full detail will be in
the daemon log

7:12

12.0

Global User Guide

Monitoring Command Progress

7.6.3

Error No

Symptom

Reason

614

Update failure - database pages are The database file is corrupt at the
not contiguous
destination. This database must be
recovered from its primary location.

628

Failed database copy. File in use. Database file is locked and overwriting
Cannot remove
is disabled. File copy has failed to
commit the .admnew file. The .admnew
file will be retained for later use.

630

Failed database copy - update for Prevention of an inconsistent extract

previous extract failed
hierarchy. A file copy for an extract db
has not been attempted because of an
update failure on another extract of the
same database. (Not fully working at
Global 2.4)

Failed File Copies

In the case of a failed copy, 2-3 failure messages may be generated to report detail. In the
example below, a SYNCHRONISE command was used and took 4 attempts to succeed. (A
failed SYNCHRONISE or UPDATE on an individual database will retry until it succeeds or
times out.) For scheduled updates, these 4 attempts would be spread over several different
update events.

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

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

characters long

be

3 A project code should be exactly three 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
system database

PDMS The daemon has been unable to find and to then open
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
reference attribute LOCRF. If the Global project has
current location
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
that does not appear to match the hostname of the
processor
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.1

Progress Messages
When the daemon is running and updates are taking place, the daemon will output
messages about the progress of the transfer. These will be sent to the window in which you
started up the daemon, but you can redirect this to a diagnostics file. You should always set
up a diagnostics file if you are running the daemon as a background process, as there is no
other way of viewing the messages.
If the daemon is running but there are problems with the data it is receiving, you may need
to contact your AVEVA Support Office. You may be asked to generate more information

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

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).

9.1

Creating Off-line Locations

Locations are created as off-line locations by setting the Off-line option on the Generate
Location form. See Creating Location Files. A project is installed at an off-line location by
transferring the files from the Transfer directory in the same way as an on-line location. Offline locations do not require initialising, and you do not need to start up a Global daemon.
Note: An off-line location cannot have on-line connections with any other location.

9.2

Transfer Directories for Off-line Locations

Just as the Hub has a Transfer directory to which files are copied before transfer to a
Satellite, an off-line Satellite must have a Transfer directory to which files containing the
updates from the Satellite's primary databases are copied before being transferred to the
Hub, and to which files are written when they arrive from the Hub, ready to update the offline location's secondary databases.

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 online 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

9.3

Transferring Updates to Off-line Locations

At the Hub:
To create the files for transfer to the Satellite, first make sure that the subdirectories in the
Transfer directory are empty.
Select Utilities>Offline Transfer, and the Offline Data Transfer form will be displayed.

Set the Transfer Operation gadget to Export Data.

The Project Locations text pane lists the locations available for transfer. At the Hub this is
a list of all the off-line locations. At an off-line location this will only show the Hub.
The Hub stores a list of databases allocated to the off-line location. ADMIN will copy all the
databases allocated to the location to the Transfer directory. The data is then physically
transferred to the Satellite by some means.
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

9.4

Transferring Updates from Off-line Locations

At the Satellite:
The Administrator at the Satellite will make sure that the subdirectories in the Transfer
directory are empty
Select Utilities>Offline Transfer, and the Offline Data Transfer form will be displayed.
Set the Transfer Operation gadget to Export Data and press OK. All the databases
allocated to the location will be copied to the Transfer directory.
Transfer the data to the Hub.
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

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.

Admin

Save Work
Get Work
Session Comment...
Modules
>
Exit

Display

Admin Elements . . .
Command Line . . .

Query

>

Project
>
Global States >

User Status
Users . . .
Teams . . .
DBs . . .
Database Sessions . . .
MDBs . . .
Stamps . . .
Locations . . .
DB Allocation . . .
Location Groups . . .
Update Events . . .
Data Access Control. . .

Locking & Isolation . . .

Communications . . .

A:1

12.0

Global User Guide

Menu Maps

Settings

Display Mode
>
Change Password . . .
Global Extract Range
Daemon Settings . . .
Transaction Timings
Transaction DB Merge/Purge

Names
Descriptions
Resize Admin Elements form
Setup Admin Elements form
Manage User Config file >

Utilities

Project

Load Current Config

Save Current Config
Reset Config to Defaults
Delete YOUR config

Integrity Checker . . .
Send Message . . .
Transactions
Design Manager IMPORT . . .
Offline Transfer . . .

Information...
Font Families...
Module Definitions...
Replicate
>
Expunge
>
Data Access Control
Initialise Location

Project data . . .
Project structure . . .
Standalone . . .
Satellite . . .
All Users . . .
User process . . .
Claimlist . . .
Picture Files
Database Files

A:2

12.0

Global User Guide

Menu Maps

Data

Merge Changes . . .
Backtrack Changes . . .

Change Management >

Inter-DB Macros...
Extract Database Control
Database Allocation >
Update . . .
Synchronise . . .
Recover
>

By Database . .
By Location . . .
Update order . . .
Database . . .
Primary Location . . .*
Hub *

*available Only if a Change Primary Location or Change Hub Location operation has failed.

Remote

Install >

Remote Change Management >

Locking & Isolation . . .
Data Recovery . . .
Synchronisation . . .
Recover Database
Remote Expunge
Integrity Checker

Sample Project
>
Foreign Master DBs >
Local Master DBs >

Merge Changes

Foreign Master DBs

Local Master DBs
List of DBs

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
Admin
Elements form . . . . . . . . . . . . . . . . . 4:2
Admin daemon . . . . . . . . . 2:1, 3:1, 3:5, 4:4
diagnostics . . . . . . . . . . . . . . . . . . . . 8:2
progress messages . . . . . . . . . . . . . 8:2
stopping . . . . . . . . . . . . . . . . . . . . . 4:11
Allocation . . . . . . . . . . . . . . . . 4:8, 4:17, 5:2
of databases . . . . . . . . . . . . . . . . . . . 3:8
Allocation order . . . . . . . . . . . . . . . . . . . . 5:6
Ancestor (Location) . . . . . . . . . . . . . . . . . 3:3
Area number . . . . . . . . . . . . . . . . . . . . . . 5:9

creation . . . . . . . . . . . . . . . . . . . . . . 3:1
de-allocation . . . . . . . . . . . . . . . . . . 5:7
deleting . . . . . . . . . . . . . . . . . . . . . . 5:9
foreign . . . . . . . . . . . . . . . . . . . . . . . 3:8
merging sessions . . . . . . . . . . . 3:7, 5:16
non-propagating . . . . . . . . . . . . . 3:8, 5:9
scratch . . . . . . . . . . . . . . . . . . . . . . . 3:8
updates . . . . . . . . . . . . . . . . . . . . . . 3:6
De-allocation . . . . . . . . . . . . . . . . . . . . . 5:7
Deleting
Databases . . . . . . . . . . . . . . . . . . . . 5:9
Locations . . . . . . . . . . . . . . . . . . . . 5:13
Descendant (Location) . . . . . . . . . . . . . . 3:3
DRAFT . . . . . . . . . . . . . . . . . . . . . . . . . . 3:9

C
Child (Location) . . . . . . . . . . . . . . . . . . . . 3:3
Command Transactions . . . . . . . . . . . . . 5:6
Commands . . . . . . . . . . . . . . . . . . . . . . . 7:1
managing . . . . . . . . . . . . . . . . . 7:3, 7:6
Communications
networks . . . . . . . . . . . . . . . . . . . . . . 3:3

E
Environment variables . . . . . . . . . . . . . . 4:7

F
Foreign Databases . . . . . . . . . . . . . . . . . 3:8

Daemon . . . . . . . . . . . . . . . . . . 2:1, 3:1, 3:5

Data Access Control . . . . . . . . . . . . . . . . 5:1
Data integrity checking . . . . . . . . . . . . . 5:21
Data recovery . . . . . . . . . . . . . . . . . . . . . 6:3
remote . . . . . . . . . . . . . . . . . . . . . . 5:20
Database . . . . . . . . . . . . . . . . . . . . . . . . . 3:2
allocation . . . . . .3:1, 3:8, 4:8, 4:17, 5:2
area . . . . . . . . . . . . . . . . . . . . . . . . . 5:9
backtracking . . . . . . . . . . . . . . . . . . . 3:7
compaction . . . . . . . . . . . . . . . . . . . . 3:7

Global . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1
Global Daemon
running check . . . . . . . . . . . . . . . . 4:14
service configuration . . . . . . . . . . . 4:13
Groups . . . . . . . . . . . . . . . . . . . . . . . . . 5:13
root . . . . . . . . . . . . . . . . . . . . . . . . . 5:13

H
Hostname . . . . . . . . . . . . . . . . . . . . . . . . 4:4

Index page i

12.0

Global User Guide

Hub
location . . . . . . . . . . . . . . . . . . . . . . . 4:3
Hub Location
changing . . . . . . . . . . . . . . . . . . . . . 5:11
recovering . . . . . . . . . . . . . . . . . . . . 5:12

Initialising Locations . . . . . . . . . . . . . . . 4:14

Installing Project
at Satellite . . . . . . . . . . . . . . . . . . . . . 4:9
Integrity checking . . . . . . . . . . . . . . . . . 5:21
Inter-db macros . . . . . . . . . . . . . . . . . . . 6:10
ISODRAFT files . . . . . . . . . . . . . . . . . . . 3:9
Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1
remote . . . . . . . . . . . . . . . . . . . . . . 5:17

Parent
(Location) . . . . . . . . . . . . . . . . . . 3:3, 4:5
Pending file . . . . . . . . . . . . . . . . . . . . . . 3:6
Picture files . . . . . . . . . . . . . . . . . . . . 3:9, 5:9
Plot files . . . . . . . . . . . . . . . . . . . . . . . . . 3:9
Primary Location
recovering . . . . . . . . . . . . . . . . . . . 5:10
Project
making . . . . . . . . . . . . . . . . . . . . . . . 4:1
Replication . . . . . . . . . . . . . . . . . . . 5:14
Projects . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
Propagation . . . . . . . . . . . . . . . . . . . 3:1, 3:6
non-propagating files . . . . . . . . . . . . 5:9
Propagation order . . . . . . . . . . . . . . . . . 5:6

Location . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
code . . . . . . . . . . . . . . . . . . . . . . . . . 4:4
creating . . . . . . . . . . . . . . . . . . . . . . . 4:7
deleting . . . . . . . . . . . . . . . . . . . . . . 5:13
description . . . . . . . . . . . . . . . . . . . . 4:4
Groups . . . . . . . . . . . . . . . . . . 3:4, 5:13
id . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:4
initialising . . . . . . . . . . . . . . . . . . . . 4:14
name . . . . . . . . . . . . . . . . . . . . . . . . 4:4
off-line . . . . . . . . . . . . . . . . . . . . 3:4, 9:1
Primary . . . . . . . . . . . . . . . . . . 3:1, 4:15
Secondary . . . . . . . . . . . . . . . 3:1, 4:15
Location Groups
root . . . . . . . . . . . . . . . . . . . . . . . . . 5:13
Locking . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1
remote . . . . . . . . . . . . . . . . . . . . . . 5:17

Recovering
Hub Location . . . . . . . . . . . . . . . . . 5:12
Primary Location . . . . . . . . . . . . . . 5:10
Transaction Database . . . . . . . . . . . 6:5
Recovery of data . . . . . . . . . . . . . . . . . . 6:3
remote . . . . . . . . . . . . . . . . . . . . . . 5:20
Remote operations . . . . . . . . . . . . . . . . 5:14
Replication . . . . . . . . . . . . . . . . . . . . . . 5:14
Root
of Location Group . . . . . . . . . . . . . 5:13

M
MDBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
Merging/Purging a Transaction Database 7:7
Messaging . . . . . . . . . . . . . . . . . . . . . . . . 6:7
Monitoring commands . . . . . . . . . . . . . . . 7:1

N
Networks
communications . . . . . . . . . . . . . . . . 3:3
Non-propagating files . . . . . . . . . . . 3:8, 5:9

O
Off-line Locations . . . . . . . . . . . . . . . . . . 9:1

S
Satellites . . . . . . . . . . . . . . . . . . . . . . . . .
Scratch
databases . . . . . . . . . . . . . . . . . . . .
files . . . . . . . . . . . . . . . . . . . . . . . . .
Sessions . . . . . . . . . . . . . . . . . . . . . . . . .
Synchronisation
(see also updates) . . . . . . . . . . . . . .
System Database . . . . . . . . . . . . . . . . . .

4:9
3:8
5:9
3:6
6:2
3:2

T
Transaction
database . . . . . . . . . . . . . . . . . . . . .
Event Timings . . . . . . . . . . . . . . . . .
Transaction Messages
managing . . . . . . . . . . . . . . . . . . 7:3,
status . . . . . . . . . . . . . . . . . . . . . . . .
Transfer Directory
off-line Locations . . . . . . . . . . . . . . .
Transfer directory . . . . . . . . . . . . . . . . . .

Index page ii

3:6
7:6
7:6
7:3
9:1
4:6

12.0

Global User Guide

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

Index page iii

12.0