Global User Guide

Global User Guide
AVEVA Solutions Limited
Disclaimer
1.1 AVEVA does not warrant that the use of the AVEVA software will be uninterrupted, error-free or free from
viruses.
1.2 AVEVA shall not be liable for: loss of profits; loss of business; depletion of goodwill and/or similar losses; loss of
anticipated savings; loss of goods; loss of contract; loss of use; loss or corruption of data or information; any
special, indirect, consequential or pure economic loss, costs, damages, charges or expenses which may be
suffered by the user, including any loss suffered by the user resulting from the inaccuracy or invalidity of any data
created by the AVEVA software, irrespective of whether such losses are suffered directly or indirectly, or arise in
contract, tort (including negligence) or otherwise.
1.3 AVEVA's total liability in contract, tort (including negligence), or otherwise, arising in connection with the
performance of the AVEVA software shall be limited to 100% of the licence fees paid in the year in which the user's
claim is brought.
1.4 Clauses 1.1 to 1.3 shall apply to the fullest extent permissible at law.
1.5 In the event of any conflict between the above clauses and the analogous clauses in the software licence under
which the AVEVA software was purchased, the clauses in the software licence shall take precedence.
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, or is validly licensed by, AVEVA Solutions Limited or its subsidiaries.
All rights are reserved to AVEVA Solutions Limited 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 Limited. Where such permission is granted, it expressly requires
that this copyright notice, and the above disclaimer, 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 Limited. The user may not reverse
engineer, decompile, copy, or adapt the software. Neither the whole, nor part of the software described in this
publication may be incorporated into any third-party software, product, machine, or system without the prior written
permission of AVEVA Solutions Limited, save as permitted by law. Any such unauthorised action is strictly
prohibited, and may give rise to civil liabilities and criminal prosecution.
The AVEVA software described in this guide is to be installed and operated strictly in accordance with the terms
and conditions of the respective software licences, and in accordance with the relevant User Documentation.
Unauthorised or unlicensed use of the software is strictly prohibited.
Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved. AVEVA shall not
be liable for any breach or infringement of a third party's intellectual property rights where such breach results from
a user's modification of the AVEVA software or associated documentation.
AVEVA Solutions Limited, High Cross, Madingley Road, Cambridge, CB3 0HB, United Kingdom.
Trademark
AVEVA and Tribon are registered trademarks of AVEVA Solutions Limited or its subsidiaries. Unauthorised use of
the AVEVA or Tribon trademarks is strictly forbidden.
AVEVA product/software names are trademarks or registered trademarks of AVEVA Solutions Limited or its
subsidiaries, registered in the UK, Europe and other countries (worldwide).
The copyright, trademark rights, or other intellectual property rights in any other product or software, its name or
logo belongs to its respective owner.
Global User Guide
Revision Sheet
Date Version Comments / Remarks

September 2011 12.1.1 Issued
January 2012 Copyright added to all pages.
January 2013 12.1.SP3 New section 10 Global Scheduler added.
Global User Guide
Global User Guide
Global User Guide
Contents Page
Global User Guide

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
Propagating and Non-propagating Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:8
© Copyright 1974 to current year. i 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
Global User Guide
Foreign Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:8

Working Extracts used as Non-Propagating Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:8
Working Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:9
DRAW Picture and Neutral Format File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:9
Compulsory Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:9
Other Non-propagating Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:9
Transfer of Other Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:9
Transfer of Linked Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:10
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 Creating Location Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:7
Creating Location Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:7
Notes on Newly Generated Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:10
Installing a New Project at a Satellite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:10
Running the Global Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:10
Location of Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:11
Using the admind command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:12
Single Project Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:13
Multiple Project Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:14
Control the Daemon from the Control Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:15
Initialising a New Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:16
Setting Primary Locations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:17
Database Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:19
How Databases are Allocated to Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:20
Allocating New Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:21
Creating Update Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:21
Managing Scheduled Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:23
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:24
Backing Up and Restoring Global Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:24
Hub Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:1

Data Access Control and Stamps in a Global Project . . . . . . . . . . . . . . . . . . . . 5:1
© Copyright 1974 to current year. ii 12 Series

Global User Guide
Database Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:2

Checking Communications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:2
Allocating a Database to a Location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:2
Checking Database Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:5
More Notes on Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:5
Allocation Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:6
Database Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:7
De-allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:8
What Happens When Databases are Allocated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:9
Deleting Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:10
Using Different Database Areas in Global Projects . . . . . . . . . . . . . . . . . . . . . 5:10
Non-propagating Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:10
Changing the Primary Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:11
Recovering the Primary Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:11
Changing the Hub Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:12
Deleting Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:14
Location Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:14
Replication in a Global Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:15
Remote Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:15
Global Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:16
Remote Locking and Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:18
Remote Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:19
Remote Data Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:20
Remote Expunging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:22
Remote Database Integrity Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:22
Querying Remote Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:23
Administering System Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:26
Verify Daemon Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:26
Local Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1

Locking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1
Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1
Unscheduled Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1
Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:2
Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:3
Data Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:3
© Copyright 1974 to current year. iii 12 Series

Global User Guide
Recovering Secondary Databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:4

Recovering Primary Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:4
Recovering the Global Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:5
Recovering the Transaction Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:5
Recover Database Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
Global Scheduler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:1

Extract Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:1
Schedule Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:2
© Copyright 1974 to current year. iv 12 Series

Global User Guide
Admin Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:4

Create a New Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:10
Delete a Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:11
© Copyright 1974 to current year. v 12 Series

Global User Guide
© Copyright 1974 to current year. vi 12 Series

Global User Guide
Introduction
1 Introduction
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 makes sure 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 the user needs to know before starting to work
with a Global project. It describes how to use Global to set up and administer a Global
project.
It is assumed that the user will be working through the graphical user interface (GUI): the
commands underlying the interface are described in the Administrator Command Reference
Manual.
Refer to Running Global Projects for further information about 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 the user is 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

The Global User Guide is divided into the following sections:
Overview of Global is an overview of the application.
Concepts describes the basic concepts of using AVEVA Global.
Setting up a Global is a step-by-step description of how to make a Global project,

Project starting from a standard project.
© Copyright 1974 to current year. 1:1 12 Series

Global User Guide
Introduction
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.
Monitoring Command describes how to monitor the progress of Global commands

Progress and, if necessary, cancel commands.
Global Daemon describes some of the messages that may be output by the
Messages 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.
1.3 Other Documentation

The user may need to refer to the following documentation:
Global Server Installation Guide describes how to install the files needed to run Global.
AVEVA Licensing System (ALS) 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.

Global User Guide
Overview of Global
2 Overview of Global
AVEVA Global provides a simple and cost-effective administration and management system
for Global projects, where data is distributed across a number of locations. To the engineer
using the base product, it should be largely invisible that the project is distributed over many
locations.
The first step is to configure 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 make sure 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 make sure the daemon is running, otherwise
there will be a substantial delay on SAVEWORK in contacting the daemon.
After a Global project is set up, the user can use Data Access Control (DAC) to control
users’ access to elements. For information about DACs in a Global project, refer to 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.

Global User Guide
Overview of Global

Global User Guide
Concepts
3 Concepts
This section describes the basic concepts of setting up a Global project using a small
project as an example.
3.1 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.

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 the user can create and modify:
• Teams
• Databases (except for working extracts, which can be created at Satellites)
• Roles (if 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 give the command to make the project Global.
Note: The location at which the user makes the project Global becomes the Hub: this
location can be changed later. Making the project Global splits the standard System
database into a new 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 Satellite’s System database. The Hub System database, like the
Global database, can only be modified at the Hub.
Note: The local system database filename is of the form prjsys, where prj is the project
code. There will also be a file of the form prjsys_loc for other locations: this is for use
in centralised administration (i.e. where one location administers all of the other
satellites remotely.).
• Once a project has been converted to a Global project, it cannot be converted back to a
standard project. In effect, a single-location Global project will behave like a standard
project, as far as most base product users are concerned. However, the user 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 the user makes a project Global, a transaction database is also created, to store
details about the progress of issued commands. Global provides a facility so that the user
can monitor the progress of Global commands, and, if necessary, cancel commands that
have not been carried out yet. Refer to Monitoring Command Progress for further
information.

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. Refer to 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, refer to Location Groups.
Hub
Hub A
Satellite Satellite
Satellite Satellite B 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.

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.
• 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 off-
line connections.
3.4.2 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.

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 Satellite’s 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 Satellite’s
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.

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. Refer to 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:
• 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 issuing a series of commands, it is essential that
one command has executed completely before the next one can be carried out.
• The user can monitor the progress of commands that operate over Global locations, by
using the Command Transactions window. Refer to Monitoring Command Progress for
further information.
More information about specific operations is given in the appropriate sections of this
manual.
3.5.2 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.
Refer to Monitoring Command Progress for further information about the transaction
database, and how to 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 Satellite’s transaction
database, the ALLOCATE and CHANGE PRIMARY commands. Refer to Pending File in
Running Global Projects for further information.
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 makes sure 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).

Global User Guide
Concepts
Before the automatic updating can start, Update events must be created 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. Refer to Running Global
Projects (section Propagation of Databases of Access-Type Update) for further
information.
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 5 Session 5 Session 5
Location AAA Hub Location AAA 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. Refer to Running Global Projects (section
Propagation of Databases of Access-Type Update) for further information.
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, the user can manually request that the databases are updated
at any time the communication link is available.

Global User Guide
Concepts
All updates will be based on the most recent state of the databases, deduced by comparison
of databases. This makes sure data integrity, even if previous updates have been lost.
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 Propagating and Non-propagating Files
3.8.1 Foreign Databases

In a Global project, the user 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 the user wants to propagate foreign databases,
they must be local databases in another Global project.
3.8.2 Working Extracts used as Non-Propagating Databases

The user 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.

Global User Guide
Concepts
3.8.3 Working Extracts

Working extracts exist only at the Satellite and are never propagated.
3.8.4 DRAW Picture and Neutral Format File

The user can choose whether DRAW 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
DRAW 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;
Marine Hull Drawing
Diagram
Stencil
Template
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.
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. The user 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.
For example, myfile has been produced at Satellite AAA and is needed at neighbouring
location BBB. The user at AAA must make sure 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

Global User Guide
Concepts
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.8.8 Transfer of Linked Documents

As an alternative to the general Transfer of Other Data, it is possible to enable propagation
of Linked documents for a project. This allows the document name to be specified in a
Design database, using a Link Description element (LNDESC) with a file URL and link
propagation. Not all linked documents will be propagated; only those for which propagation
has been explicitly enabled (attribute LNKPRP SEND).
This allows documents to be managed alongside the database to which they are linked.
Linked documents will be transferred from the primary location of the database to secondary
locations. Documents will only be copied if they are missing. Normally if a file is already
present, it will not be overwritten, unless a command such as RECOVER is being used.
In order for a document to be propagated successfully, the specified folder must exist at the
destination locations. For this reason, it is useful to store such documents in project-related
folders, which are also likely exist at the satellite.
Linked documents will be transferred as a separate operation after the relevant Design
database has been updated. Only missing files will be transferred.
In order for Linked documents to be transferred:-
• The project must have Linked document propagation enabled
• Linked Document propagation must not have been disabled for the Design database
• The Link description (LNDESC) must have LNKPRP SEND
• The Link URL must be a file URL ('file:///my_path_name') which references a valid file
location
Linked documents will only be transferred as part of an update if a database update was
required. There is a separate command to Synchronise Linked documents for a database.
Linked documents will always be copied when a database is Allocated or Recovered.
House-keeping operations for Linked documents are not supported by Global. Thus if a
database is deleted or de-allocated, its linked documents will not be tidied.
3.9 Multiwrite Databases in a Global Project

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

Global User Guide
Setting up a Global Project
4 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 making a project Global, the following stages must have been completed (refer to
Administrator User Guide for further information):
1. A standard project should already exist at the location which will become the project
Hub, and its project environment variables should be set. The project may be created
using E3DMAKE or similar. The folders abc000, abcmac, abcpic and abciso must
exist, plus any folders required by specific applications (such as abcdia, abcste,
abctpl for Schematics; abcmar, abcdrg for Marine etc)
These foldernames are mentioned in more detail in Using the admind command.
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 the user can carry
out the entire process locally on a LAN before distributing it to the Hub and Satellite
locations. Before sending the project to the satellite location, the satellite’s RHOST
attribute needs to be modified. The user must copy this change to the Global database
manually.
The user 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, 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. When finished making changes, 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

Global User Guide
The make global command splits the System database as described in System and Global
Databases. If the user lists the files in the project directory from the operating system, a new
database named projglb is visible, where proj is the three-character project code.
At this stage, the Hub does not have a transaction database. When created for the first
Satellite location from the ADMIN GUI, a transaction database is 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: A transaction database must be created 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.
A message is displayed that the Hub is uninitialised: which means that setting up the Hub is
the first task.
The main menu bar is slightly different: it shows the current location, and also which location
is currently Administering:
If required 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. Refer to Data Access Control and Stamps in a Global Project for further
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 on the
Admin Elements window.

Global User Guide
Figure 4:1. The Admin Elements window
If looking at the Databases version of the Admin Elements window, 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 window, select Locations from the Elements option. 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.
Click Modify on the Admin Elements window, to display the Modify Location window.
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.

Global User Guide
The Name will appear on the Admin Elements window. 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 Overwrite DB Users 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: Do 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:

Global User Guide
• 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.
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 the user wants 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 starting
create extracts, 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 1 - 3000
(seen wherever allocated)
Working Extracts, Location HUB 3001-4000

Global User Guide
Range Type Number Range

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.
Below the heading Transaction Database the user can specify a DataBase Number for the
Transaction database and its description. Click System to allow the software to
automatically generate a free database number.
An example of a completed Modify Location window is shown:
Make any changes needed and click Apply. A prompt is displayed asking whether to
initialise the Hub now:

Global User Guide
• Click Yes, the Hub will be initialised with the current settings on the window. These
settings can be changed later, if necessary. Make sure that the Hub has a transaction
database before its initialised.
Note: Once the Hub is initialised, you cannot normally change the following settings:
• Location ID
• Hostname
However, if required to transfer the Hub to a different machine, (for example, because
of a systems crash) 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.
• Click No, the values entered on the window is stored, and are still editable to change
them.
• Click Dismiss, the window is closed and any changes lost, as normal.
If the user decides not to initialise the Hub at this stage, it can be initialised 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 Creating Location Files

Before setting up a new location:
1. 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 are copied into this directory, ready for
transferring to the actual location.
2. An environment variable of the window must be set:
XXX_LOC
where XXX is the project code, in this case ABC, and LOC is the location identifier, in
the following example OXF, which specifies where to 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,
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 window 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 window, to display the
Create Location window:

Global User Guide
The Name appears on the Admin Elements window.

The Location ID is a three-letter code that identifies the location.
The Description is optional.
Connection will normally be on-line. Refer to Off-line Locations for further information.
Hostname is the identifier of the machine on which the Global daemon will be running at the
location.
Note: Make sure that the Location ID and Hostname are correct. Click Apply, 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. (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.

Global User Guide
All Global extracts are given an identifying number when they are created. Before starting
create extracts, work out an extract numbering system. 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 window filled in for a location identified as OXF:
Click Apply, the location and its transaction database is created. A prompt to confirm that all
the required 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, refer to Database Allocation.
The location’s transaction database is already primary at the Satellite. Other databases will
be transferred to the Satellite as secondary databases. The primary location can be
changed 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.

Global User Guide
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 window.
Until it is initialised, the location will not appear in other lists of locations; for example, on the
windows used for allocating databases and setting the primary locations of databases.
If required to check the status of a location, use the Query > Project > Locations option to
display the List Locations window. Select the location from the scrolling list.
4.7 Installing a New Project at a Satellite

The user 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, the user 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 (refer to Initialising a New Location). Then the Administrator at the Satellite can
create Users and MDBs.
If simulating the Location creation as a training exercise, copy the files to another directory
on your local network. Set up the normal project directories and set the project environment
variables, as if 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.
If the daemon is to be installed on a network behind a firewall or DMZ it may be necessary

to conduct additional post configuration, when using RPC refer to the Firewall Configuration
section in Running Global Projects.
The AVEVA Support website contains important information about the IT Configuration
required for Global when using RPC as the network protocol.
Note: On the AVEVA Support website the section titled “Group Policy for RPC” is not
required for Global WCF.
On the AVEVA Support website, in the section “Internet Connection Firewall” the
user must add admindWCF.exe to the list of Program Exceptions if the WCF
protocol is used. In addition the user must add the TCP port defined in the WCF
configuration files described in the Global WCF Configuration Guide (section WCF
Configuration Files) to the list of Firewall Exceptions. The user must also refer to the
section Firewall Configuration in the Global WCF Configuration Guide for a detailed

Global User Guide
description of the considerations that must be made when configuring the firewall for
WCF communications.
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:
File list when RPC Protocol is used
admind.exe libgm.dll
AdmindRPC.dll Libifcoremd.dll
attlib.dat Libmmd.dll
demonservicemulti.exe message.dat
demonservicesingle.exe multids.bat
dop.exe project files (inc *vir.dat)
globalStartRPC.dll singleds.bat
libfl.dll Zlib.dll
libgeom.dll
File list when WCF Protocol is used
admindWCF.dll GlobalWcfService.dll
GlobalToWcfClientWrapper.dll GlobalWcfContracts.dll
globalStartWCF.dll WcfToGlobalServerWrapper.dll
GlobalToWcfServerWrapper.dll admindWCF.exe
admindWCF.exe.config libifcoremd.dll
libifportmd.dll libmmd.dll
GlobalWcfHelpers.dll globalWCFClient.config
In addition the Microsoft Enterprise libraries will be present when WCF is used:
Microsoft.Practices.EnterpriseLibrary.Common.dll
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll
Microsoft.Practices.EnterpriseLibrary.Logging.dll
Microsoft.Practices.EnterpriseLibrary.Validation.dll
Microsoft.Practices.EnterpriseLibrary.Validation.Integration.WCF.dll
Microsoft.Practices.ObjectBuilder2.dll

Global User Guide
4.8.2 Using the admind command

The Global daemon is started by using the admind command (or admindWCF command if
the WCF protocol is used). For the admind command to run correctly 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 AVEVA_DESIGN_EXE to the folder where Global is installed.
• Set AVEVA_DESIGN_WORK 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.
• Make sure that the AVEVA_DESIGN_EXE 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 AVEVA Licensing System (ALS) guide.
• If transfer of other data files is required (refer to 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.
Example:
set AVEVA_DESIGN_EXE=base product install path

set ABC000=%AVEVA_DESIGN_EXE%\projects\abc000
set AVEVA_DESIGN_WORK=c:\temp
set SAM000=%AVEVA_DESIGN_EXE%\project\sam000
set SAMMAC=%AVEVA_DESIGN_EXE%\project\sammac
set SAMPIC=%AVEVA_DESIGN_EXE%\project\sampic
set path=C:\AVEVA_DESIGN_EXE% (you need this in order for th
e base product to contact the daemon)
set USERNAME=SYSTEM
%AVEVA_DESIGN_EXE%\admind start ABC
When the Ready message is visible, the daemon is running.

Global User Guide
For more information about the Global daemon, and what to do about possible problems,
refer to Global Daemon Messages.
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 required 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 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:
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):

Global User Guide
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
If WCF protocol is used:-
start ‘Project bas’ /MIN base product install path\admindwcf.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
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.

Global User Guide
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.
To display the Services window, 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, 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. Refer
to Global Installation Guide for further information.
If using multiple projects, the Global daemons for all the projects will be started. Individual
daemons cannot be stopped and started: if required 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. Right click and select Properties on the Services window, another window is
displayed which allows the user to start up the service automatically when the computer is
re-booted.

Global User Guide
Set the Startup Type as follows:

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

Global User Guide
To 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. Give this command before seeing
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:

• 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 Satellite’s
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. Refer to
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. Refer to
Creating Update Events.
If looking at the Admin Elements windows for the Satellite, notice that the buttons at
the bottom of the Teams and Databases versions are inactive: these tasks cannot be
carried out at a Satellite.
4.10 Setting Primary Locations

When a location is generated, the location’s 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 selecting one of the databases from the Admin Elements window and click Modify on the
Admin Elements window, to display the Modify Database window.
Note: The options that are inactive on this window are the attributes of the database that
cannot be modified once it has been created.

Global User Guide
Select the pull-down option at the right of the Primary Loc. text box, to display the Primary
Location window.

Global User Guide
Select a location, click OK, and then Apply the Modify Database window. 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 window for the Hub.

The following example illustrates how databases need to be allocated in a small project with
three locations:
comms link comms link
Location A (HUB) 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, DRAW/DRAW
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.

Global User Guide
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.
The databases need to be allocated, and their primary locations set, 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.
+ CATA/PIPE - CATA/PIPE - CATA/PIPE

+ CATA/STEEL - CATA/STEEL - CATA/STEEL
+ PIPE/PIPE - PIPE/PIPE - PIPE/PIPE
- STEEL/STEEL + STEEL/STEEL - STEEL/STEEL
- DRAFT/DRAFT - DRAFT/DRAFT + DRAFT/DRAFT
- ISOS/ISOS + ISOS/ISOS
Figure 4:2. 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 creating a location which does not have a direct link to the Hub, and, when prompted,
confirm that all the files copied are required:
• 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 Location B Location C
+ CATA/PIPE - CATA/PIPE Location C is about

+ CATA/STEEL - CATA/STEEL to be created
+ PIPE/PIPE - PIPE/PIPE
- STEEL/STEEL + STEEL/STEEL
+ DRAFT/DRAFT
+ ISOS/ISOS
Figure 4:3. This diagram shows the databases existing at Locations A and B, just before Location C
is created.

Global User Guide

+ DRAFT/DRAFT - DRAFT/DRAFT - DRAFT/DRAFT
+ ISOS/ISOS - ISOS/ISOS - ISOS/ISOS
Figure 4:4. This diagram shows the databases at all three locations just after Location C has been
created.

- DRAFT/DRAFT - DRAFT/DRAFT + DRAFT/DRAFT
- ISOS/ISOS - ISOS/ISOS
Figure 4:5. Now the Hub Administrator has de-allocated the ISODRAFT database from Location C
because it is not required there.
Note: That DRAW/DRAW must remain allocated to Location B. The DRAW database has
been made primary at Location C, and the ISODRAFT database has been made
primary at Location C.
Note: Display information about the locations already created by selecting Query > List >
Locations, which displays the List Locations window.
4.11.2 Allocating New Databases

Once the Global project is set up, the user can allocate any new databases required. For
information about allocating databases in a Global project, refer to Database Allocation.
4.12 Creating Update Events

For automatic updates to take place, the user 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. Only create the Update event at one of the locations in the pair.
When considering 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 hourly updates are required, create an Update event between AAA and BBB on
the hour, and an Update event between BBB and CCC on the half-hour.
The timing of Update events is particularly important between the members of a group.

Global User Guide
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 window, click Create, to display the Create Update Event window.
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. Refer to 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

Global User Guide
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.
Note: Max Retries and Retry Interval on the Update event are ignored in Global WCF since
configuration file settings are used instead.
Transfer Scripts
Enter the names of script files in the two Transfer Script text boxes. The scripts are 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, 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.
Databases can be updated manually. Refer to 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.
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 using more than one update timer, 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).

Global User Guide
Note: Schedule updates to allow time for general housekeeping activities, such as
database merging. For example, set up scheduled updates to run only between
Monday and Saturday to allow merges to take place on Sundays.
4.13 Conclusion
With a Global project up and running. The following chapters describe other tasks that the
System Administrators at the Hub and the Satellites are required to carry out.
4.14 Backing Up and Restoring Global Projects

Backing up projects is good practice in any environment: make sure that all files at all
locations are backed up regularly.
To restore a Global project, extra attention must be given to any restoring process that is
carried out.
• By using the Recover option it is possible to restore project databases, which may
minimise work loss.
• 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.
• 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 carrying out any major Global administration work.

Global User Guide
Hub Administration
5 Hub Administration
Creating Global projects and locations and configuring communication daemons have been
described in Chapter 4. This chapter adds to the information, and describes the other tasks
that will need to be carried out at the Hub. These are:
• Controlling database allocation.
• Changing the primary location of a database.
• Changing the Hub location.
There are also several tasks that the Hub Administrator can carry out remotely for a
Satellite: some of these tasks are also described in Local Administration, as they are
essentially local operations. These tasks are:
• Remotely merging changes.
• Remote locking and isolation.
• Remote synchronisation of databases.
• Remote data recovery.
• Remote removal of phantom users and elements.
• Remote integrity checking of databases (DICE).
The Hub Administrator is also responsible for the normal administration of databases
that are primary at the Hub, and the creation of Users and MDBs for the location that
happens to be the Hub. All these tasks are described in the Administrator User Guide.
5.1 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 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. Make sure that there are no General users in the project at any
location before switching 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.
• The Transfer To Parent and Child functionality fully complies with Data Access Control
as applied by the Project Administrator. Transfer To Parent adheres to rules defined by
the OpIssue access and Transfer To Child adheres to rules defined by the OpClaim
access. If either access is denied, then the operation to Transfer the item will fail.

Global User Guide
Hub Administration
Note: Remote database queries (refer to 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.

When a location is first created, 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.
The user may well not need all the databases copied to the transfer directory when the
location was generated: once the location is initialised, the user can de-allocate databases
which are not needed. Any databases created after the location has been generated (by
clicking Apply on the Create Location window) 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, make sure that both daemons are running by selecting Query
> Global States > Communications or by issuing a Ping command. The Test Project
Communications window will be displayed. Select the remote location from the list, and
click Apply.
Note: the user can also select the current location, as a preliminary check on your own
daemon.
The window 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
make sure 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 the user to change
the allocation of databases. The options are By Database and By Location. The windows
are similar, except in the way the information is organised.
The Database Allocation (By Database) window is displayed when the user selects By
Database.

Global User Guide
Hub Administration
The Project Databases scrolling list shows all the databases in the project.
• + means Primary at the current location
• - means Secondary at the current location
• * means a Foreign database (propagation of Foreign databases is under the control
of the Foreign project)
The user can Sort By a specific column in the list such as Name or Type.
The Filter gadget can be used to filter the list to show only databases with a Name that
includes the input value. An asterisk (*) can be used as a wildcard. Values entered into the
Filter gadget are case sensitive.
The Allocation details window contains two scrolling lists:
• Project Location shows all the locations to which the database is not allocated.
• Allocated To shows all the locations to which the database is allocated, and whether it
is primary or secondary at that location.
Note: The indentation in the list represents the tree structure of the communications
network.
Use the arrow buttons to change the allocation.

The Database Allocation (By Location) window is displayed when the user selects By
Location.

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 the user to copy the allocation of databases from
another location.
The Processing Options are as follows:
• If the Include descendants when de-allocating databases option is set, the
Databases which are allocated to descendants of the current Location will be de-
allocated. If this option is not set, and the user tries 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 the user requires 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, the user 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.

Global User Guide
Hub Administration
• If the Keep MDBs while de-allocating DBs option is set, then the database is de-
allocated without removing it from MDBs at the satellite. This may be useful as part of
certain house-keeping procedures, such as a temporary de-allocation to reconfigure
the database. This database will be deferred automatically by the system when a user
selects an MDB with a de-allocated database. This option should not be used when the
database is being removed permanently.
5.2.3 Checking Database Allocation

After every allocation operation, the user 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. Refer to 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 windows.
However, it is advisable to use a macro for long lists of database allocations; for example,
when a project is first set up. Refer to the ALLOCATE command in the Administrator
Command Reference Manual for further information.
Check that the allocation has completed successfully. If you select DB & Extracts from the
Admin Elements window, a list of all the allocated databases is visible.
Alternatively, 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 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

Global User Guide
Hub Administration
Utilities > Transactions to display the Command Transactions window) 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.
To display the Update Order window, 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
This button also arranges Extract databases in hierarchical order, so that the Master
precedes any child extracts.
Order the databases manually using the Allocation Order part of the window.
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.

Global User Guide
Hub Administration
To move a database from one row to another, select that database in the list, click Select
row to move option, then select the row you want to move it to, and click Move to.
5.2.6 Database Distribution

To display the Database Distribution window, select Data > Database Distribution on the
main ADMIN menu bar. This shows all the project databases and how they are distributed
across the locations.
A column is shown for each location (titled by its 3 character location id). Database status is
indicated at each location as follows:
+ indicates the database is primary at this location
- indicates the database is allocated to this location but is primary elsewhere
> indicates the database is in transit from this location under a pending
transaction
* indicates the database is foreign and allocated to this location
Use the Refresh option to update the list following any change such as the deletion of a
database or a change of primary location.
Use the Clear Selection option to clear any row selection in the Database list.
In order to change the primary location of one or more databases, select the required
databases in the upper list, and select the location where they are to be primary in the lower
list, then click Change Primary Location. The databases will be allocated if necessary to
the selected location and changed to be primary at that location.

Global User Guide
Hub Administration
5.2.7 De-allocation
When a database is no longer needed at a Satellite, it can be De-allocated.
• The user cannot de-allocate a primary database: 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.
• The user 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, do not de-allocate a Satellite’s transaction database
from the Satellite. This facility is only provided for recovery purposes, or to allow a
Satellite to be deleted.
Refer to What Happens When Databases are Allocated for a description of the allocation
and de-allocation mechanism. (Refer to Administrator Command Reference Manual,
DEALAL and DEALDB attributes.)
The procedure for de-allocating a database is shown in the following diagram:

Global User Guide
Hub Administration
5.2.8 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 make sure 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.

Global User Guide
Hub Administration
5.3 Deleting Databases

Databases can only be deleted at the Hub. Before deleting a database, the user 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

The user can use different areas for databases in Global projects in that same way as
standard projects. Make sure that the environment variable for a database’s 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 window defines
whether or not the database will be distributed, and, for a DRAW 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.

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 DRAW 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. The user 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, the user needs to
change the database’s primary location to your own location before it can be administered.
The user 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 on the Admin Elements window, and click Modify. The Create/Modify
Database window is displayed. Click the gadget at the left of the Primary Loc. text box, to
display the Primary Location window.
This window 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 window is displayed when the user selects Data >
Recover > Database > Primary Location on the main ADMIN menu bar.

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 window 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. (Refer to Administrator Command Reference Manual (CHANGE,
RECOVER, CREATE EXTRACT and ALLOCATE commands)).
5.7 Changing the Hub Location

The user 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 the user 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 the user take the following preliminary steps to minimise the risk:
• Make sure 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, Model, Draw or
Spool module.

Global User Guide
Hub Administration
• Make sure the project at the original Hub is 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. To synchronise the databases at the location that is about to become the new Hub,
which can be done locally at the Satellite, or remotely from the current Hub. Refer to
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 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. Refer to Running Global Projects for further
information
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. (Refer to
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.
Output to the Global daemon windows will indicate whether the location is now the Hub
or a Satellite.

Global User Guide
Hub Administration
5.8 Deleting Locations

Locations can only be deleted if they have no allocated databases. To delete a location, the
user 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.
A group is set up by creating it using the Admin Elements window, and then adding
the locations which will become its members using the Group Membership window,
which is displayed when the user clicks the button at the right of the Group text box on
the Create/Modify Location window.

Global User Guide
Hub Administration
5.10 Replication in a Global Project

The options under Project > Replicate on the main ADMIN menu allow the user 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, to
display the Replicate Project window. 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 window is displayed so that a macro filename can be specified. The
default filename is $AVEVA_DESIGN_USER/RecreateProj.mac.
Note: The following option can be used at a Satellite:
• 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.
5.11 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 the
user wants 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
The effects of these operations are the same as if they were carried out locally. Generally,
use the Remote options from the Hub, the Satellite itself, or the administering location.
However, you can use Remote > Integrity Checker from any location.

Global User Guide
Hub Administration
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 Global Change Management

Selecting Remote > Global Change Management > Global Merge Changes displays the
Global Merge Changes window.
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, the Global Merge Changes window
can be used to merge database sessions for a remote location. This will merge the
database at its primary location first, then updates the database at all available secondary
locations.
Use The Databases of option to select the remote location for which the database sessions
are to be merged.
Merge the changes to the System databases, or to a Single Project database. If Single
Project database is chosen, select a database from the Available databases list. The user

Global User Guide
Hub Administration
can merge All Changes, Changes Up to or Changes After a given time, date or session
number.
The Rebuild list option is used to update the list of databases. For example, if a new
database has been created while the window is displayed, the list will not be updated until
the window is closed and re-displayed, or the Rebuild list option is clicked.
To schedule a time for the merge to take place, click 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, click Apply 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.

Global User Guide
Hub Administration
5.11.2 Remote Locking and Isolation

To Query the Lock and Isolation states of all on-line locations by selecting Query > Global
States > Locking & Isolation, to display the Query Location Lock & Isolation window.
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 click Apply, the relevant
information will be shown next to the Lock and Isolation gadgets. When the window 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.

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 the user 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 window. Use the Synchronise Secondary Databases of option on this window
to select the location where the secondary databases are to be synchronised. The rest of
the window is similar to the Synchronise Secondary Databases window which must be
used to synchronise databases at the current location. Refer to Synchronisation for further
information.

Global User Guide
Hub Administration
5.11.4 Remote Data Recovery

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

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 the user wants 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.
Note: The options available in the Recover Database to location will depend on the
database selected

Global User Guide
Hub Administration
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 window, which is
used to expunge database claims and/or users at a remote location.
Use the Expunge at Location option 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.
Click Apply 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

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 the user does
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
window, which can be used to check the integrity of all or selected databases at a remote
location.

Global User Guide
Hub Administration
Use the Databases at Location option to select the remote location where the user wants
to check the database integrity.
The Check options allow you to choose which databases you want to check. If the option 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 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 window can be invoked in two ways:

Global User Guide
Hub Administration
Either from Admin Main Query menu bar: Query > Project > Remote File details Remote
Last Session… or Popup menu in Admin Element window: Query > Remote File details…
Remote Last Session…
Selecting the Remote File details option displays the window below.
The main function of this window 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 window with results relevant to
the last session:

Global User Guide
Hub Administration
In both windows, 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 click Apply. Now the resulting file detail or session detail of the selected database(s)
is listed on the right of the window, along with the database name – see below.
Results can be stored by entering a file name and clicking the Report option.
• 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 window.

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 Satellite’s System database is primary at the administering
location. The administering location can be the Hub or a Satellite location. If necessary,
change the location of a System database to make it primary at the administering location:
refer to 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, refer to 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.0.1 (WINDOWS-NT 5.1) (Mar 6 2009)

Global User Guide
Local Administration
6 Local Administration
The administration tasks described in this chapter may need to be carried out at the Hub or
at the Satellites. Operations on constructor databases, such as merging changes, locking,
isolation, data recovery, synchronisation, expunging and integrity checking can be carried
out remotely at a Satellite by a System Administrator, as described in Remote Operations.
6.1 Locking
Locking a Global project at a location has the same effect as locking a standard project: it
prevents users entering the project. Local locking is done in the normal way, using the
button on the main ADMIN menu bar.
You can remotely lock or unlock any or all of the project locations from the Hub, the Satellite
itself, or from the administering location, using the Remote > Locking and Isolation option.
Refer to Remote Locking and Isolation for further information.
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. Refer to Remote Locking and Isolation for further information.
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.

Global User Guide
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 window is similar
to the window for the current location, described below.
Select Data > Synchronise on the main ADMIN menu bar, to display the Synchronise
Secondary Databases window.
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.
The user can also use this window 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.

Global User Guide
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, to display the Unscheduled
Database Update window.
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.

Global User Guide
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.
The user can remotely recover databases from the Hub, the Satellite itself or from the
administering location, using the Remote > Recover Database option. The window is
similar to the Recover Databases window for the current location, described in Recover
Database Window.
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.
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
6.4.2 Recovering Primary Databases

You can recover primary databases, but because the primary database is the most up-to-
date 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:

Global User Guide
• Restore from backup if all secondary databases are older than backups or if they had
not been synchronised with the primary database before it was corrupted.
• Restore from a secondary location if it has an uncorrupted and newer database than
the one in the backup. (You should restore from the latest secondary database.)
6.4.3 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 base product 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 Recover Database Window

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

Global User Guide
Use the Recover Database to Location window 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.

Global User Guide
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 window.
6.5 Messaging in a Global Project

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

Global User Guide
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.

Global User Guide
If you need to give commands and make changes to a System database, you must first
make sure that the database is primary at your current location. Refer to Changing the
Primary Location for further information.
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, refer to 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 de-
allocated databases. This results from the Keep MDBs option while de-allocating
DBs (used during house-keeping procedures)
The displayed window 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. To remotely merge a database, refer to Global Change Management for further
information.
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.

Global User Guide
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:
• 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.
6.9 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.

Global User Guide
Monitoring Command Progress
7 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, refer to Administrator
Command Reference Manual. For information about how messages are processed, refer to
Running Global Projects.
7.1 Viewing Command Transactions

The Command Transactions window can be used to view a list of the current transactions
for the Global commands that have been issued.
This window can be launched from the MODEL, DRAW or ADMIN modules via the menu
bar Utilities > Transactions.
When viewing this window 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 window from Design.
Note: The Global Scheduler takes time to initiate the call to the Global Daemon, before the
issued command appears in the scrollable list. Refer to Global Scheduler for further
information.

Global User Guide
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
in the Command Transactions list is updated. If required, the user can view details of all the
transaction messages for a specific command, as explained in Viewing Transaction
Messages.
The user can use the Filters on the left hand side of the window 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.
Click Initialise Filters if you want to reset all filters to their default state.
You can use the following filters:
• Use User to specify which user’s commands will be displayed. General users can only
view their own commands. An Administrator can view commands for All Users, and
also commands from the ‘users’ Local Daemon, Remote Daemon and Timed Updates.
For example, by selecting Remote Daemon, the Administrator can view the remote
commands passing through the location.
• Use Module to display commands issued from that module only.
• Use Command to specify which type of commands will be displayed. The default is All
commands. The option list contains the most commonly used Global commands. If you
want to display a different Global command, set this option to All commands and use
the Text filter to make sure 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. Refer to Transaction Audit Trail
in Running Global Projects. for further information
• 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.

Global User Guide
Click 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
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 window is displayed for several minutes, click 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.
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.
7.2 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.

Global User Guide
Transaction Messages displays the transaction message history for the selected command
within the Transaction Messages window (refer to 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 window.
If you select a different command, or select a transaction message from the Transaction
Messages window (described in Viewing Transaction Messages), this window changes
automatically to show the details for the selected command or message.
Flag displays the Command Transaction Flag window, 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

Global User Guide
flagged commands only checkbox on the Command Transactions window to display flagged
command transactions only.
Clear Flag Clears the flag from the selected command

transactions.
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 window is displayed for several minutes, click Update to update the Command
Transactions list from the transaction database, re-applying the filter criteria.
Select All Selects all transactions in the Command Transactions

list.
Clear Selection Clears all selected transactions in the Command

Transactions list.
7.3 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 window is displayed, showing all the transaction
messages for the command, from when the command was issued until it was completed:
The window 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 command, which may just be temporary failure conditions, or you can view messages
arising from the Results of a completed command.

Global User Guide
You can further filter the messages displayed using the option buttons at the base of the
window.
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 window. 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 (refer to 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:

Global User Guide
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.
Click Apply to set the event timings for the selected Location to be the values displayed
currently.
Click Defaults to display the default settings for the selected Location.
Click 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
Merge/Purge from the main ADMIN menu bar. The Transaction dB Merge/Purge form is

Global User Guide
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.
Click Apply to apply the selected settings to the automatic transaction dB merge/purge
facility.
Click Defaults to set the form to the default settings of the automatic transaction dB merge/
purge facility.
Click Current Settings to set the window 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.

Global User Guide
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 details 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:

Global User Guide
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 DRAW 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’).
Note: This will always report a success even if there is nothing to transfer or ‘Other data
transfer’ is not set up.

Global User Guide
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.
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

Global User Guide

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

Global User Guide

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)
7.6.3 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.
In this case, the SYNCHRONISE command eventually succeeded, since Overwriting was
enabled.

Global User Guide
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!)

Global User Guide
Global Daemon Messages
8 Global Daemon Messages
When a project is first made Global, or when a new location is created, the daemon must be
started up at each on-line location as described in Running the Global Daemon. The
daemon should be started up on the workstation that will be connected to the remote
locations.
This chapter explains some of the messages that may be output by the daemon if there is a
problem. The messages, with brief explanations and suggestions about what to do, are
given below.
Message Meaning/action
Wrong number of arguments The start or stop command line argument is missing.
Invalid argument Attempt to use a command line argument other than
start or stop.
Project name should be 3 A project code should be exactly three characters long.
characters long It is case insensitive.
Project environment variable not The environment variable (in the form ABC000) is not
set set. Set the environment variable and then retry.
Project directory not found The environment variable (in the form ABC000) is set
but it does not appear to point to a valid directory.
RPC communication problem You cannot communicate with other locations. There
appears to be a problem with the installation of the
underlying communications software. Refer to 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.
Cannot find/open System The daemon has been unable to find and to then open
database for project 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.

Global User Guide
Cannot find/open Global The daemon has been unable to find and to then open
database for project 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.
Cannot find/open Comms The daemon has been unable to find and to then open
database for project the comms database in the project directory. Check
that the environment variable is pointing to the correct
directory and that the directory contains a project.
Unable to find the reference to The STAT element in the System database contains a
the current location reference attribute LOCRF. If the Global project has
been created properly, then the LOCRF attribute will
correctly point to a Location element in the Global
database. This problem could arise if the wrong
System database had been copied manually to a
location.
Unable to find the name of the The STAT element in the System database contains a
current location reference attribute LOCRF. If the Global project has
been created properly, then the LOCRF attribute will
Incorrect System DB
correctly point to a Location element in the Global
database.
Hostname has not been set for The Location element contains an attribute RHOST
this location that does not appear to have been set.
Attempt to run daemon on The Location element contains an attribute RHOST
processor … that does not appear to match the hostname of the
Hostname for this location current workstation.
should be …
Cannot start database thread One of the main sub-systems of the Global daemon
has not started. Try to restart the daemon; if it
continues to fail then please report the problem to
AVEVA Customer Services.
Cannot start timer thread One of the main sub-systems of the Global daemon
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

Global User Guide
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, refer to the on-line help for further information.
The diagnostics are not available for off-line locations.

Global User Guide

Global User Guide
Off-line Locations
9 Off-line Locations
This section describes how to create and install an off-line location, and the tasks that are
required only at off-line locations. The tasks are:
• Transfer from the Hub to the off-line Satellite.
• Transfer from the off-line Satellite to the Hub.
• Removal of old database and Picture files.
The only communication for off-line locations is between the location itself and the Hub.
Transfer is by means of a tape or other media.
Note: Using off-line locations limits the Global functionality which can be used. Updates will
have to be transferred manually, for example, by writing a tape. The Remote
operations are not available for off-line locations.
If using extracts, the entire extract hierarchy must be primary or secondary at the offline
location. You cannot have some extracts primary at the offline location and some at other
locations, since certain operations such as claiming and flushing will fail (refer to Running
Global Projects manual for further information). 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 window. Refer to 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. Off-line 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 off-
line location's secondary databases.

Global User Guide
Off-line Locations
Environment variables must be set at both the Hub and the Satellite to point to the Transfer
directory at each location.
Example:
The project code is ABC.
Cambridge is the Hub, with the location identifier CAM.
There are two off-line Satellites:
• Sydney has the location identifier SYD;
• Perth has the location identifier PER.
The transfer directory at the Hub has a subdirectory for each location:
pathname\sydney
pathname\perth
Each subdirectory will have the normal project-related directory structure, abc000, abcmac,
etc.
Note: The transfer directory is used in the same way as the transfer directory for an on-line
location when the location is first generated. You can delete the directories for an on-
line location once the project has been installed there, but you should keep the
directories for the off-line locations, as they will be used for transferring updates.

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.

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

Global User Guide
Global Scheduler
10 Global Scheduler
Note: The Global Scheduler is AVEVA E3D™ only.
The Global Scheduler allows Project Administrators to better manage Distributed Extract
Hierarchies. It is possible to configure the scheduler to run key extract operations without
needing Designer interaction. It also reduces the amount of Global and Extract knowledge
required by the Designers in Plant development. Once the Designer has completed an
operation and it needs to be transferred. How and what time the data is transferred is
controlled by the Project Administrator by setting up a series of regular scheduled Extract
Operations that are managed by the Global Scheduler. Schedules can be set-up to run on a
regular basis, with little or no further administration tasks needed.
The Project Administrators can set up projects to send latest information around Extract
Hierarchies without requiring any interaction. Designers will need to identify elements that
need to be relocated, and mark them for relocating. So when a Designer has completed all
tasks for an item they either need to leave it (remains at the current location), or transfer it
(the item gets relocated to the remote location). The designer does not need to worry where,
or if the command completes, but just needs to transfer the item. The system takes care of
the rest.
The Global Scheduler allows the Project Administrators to set up Controlled Data Item
Transfer.
Note: Controlled Data Item Transfer is only available in Model. Refer to Common
Functionality User Guide (section Global).
Schedules can be set to repeat at regular intervals. Running frequent schedules is good
practice as it minimizes the data differences between locations and helps make sure the
right elements are in the right location at the right time, which can improve productivity.
10.1 Extract Set-Up

The diagram below displays an example of setting up extract hierarchies for Extract
Transfer:

Global User Guide
Global Scheduler
10.2 Schedule Set Up

The Administrator needs to consider how and when items should be transferred. There are
two types of commands that can be scheduled:
• Non-transfer makes sure that the remote location is updated to see all modifications.
• Transfer not only updates the remote location but also transfers the location where
elements are to be modified.
As there are two directions (Master to Extract / Extract to Master) there are a total of four
modes of transfer to consider when setting up schedules (these map to traditional extract
functionality):
• Transfer to Child - (Extract Claim to the child extract)
• Transfer to Parent - (Extract Issue to Master)
• Non-Transfer to Child - (Extract Refresh to child extract)
• Non-Transfer to Parent - (Extract Flush to Master)
Schedule implementation would depend on the time zones but it is recommended that the
Administrators set regular schedules for keeping the remote locations up to date with
changes (non-transfer) for example every hour, and less regular item transfer schedules (for
example once or twice a day).
To make the schedule process most efficient it is best to precede schedule commands with
an update command. Although each of the commands include a database propagation
operation running the update keeps the transfer process light.
An example of schedules for a location would be:
• Run Update every hour on the hour - 00:00
• Refresh child extracts at 10 minutes past the hour - 00:10
• Flush child extracts at 15 past the hour - 00:15
• Claim Data in the child twice a day, lunch time 12:30 and evening 19:00
• Issue Data twice a day, lunch time 13:00 and Evening 19:30

Global User Guide
Global Scheduler
When locations reside in different time-zones the schedules need to be synchronised to

allow for the shift in the time difference. In the example below there are three locations in
Asia, Europe and the Americas. The diagram provides a possible set-up that makes sure
data is shared between all locations regularly, with items location being transferred twice a
day. The transfers try to follow the sun. The flow is to make sure that items are relocated on
a half daily basis.
A Schedule can be created between 00:01 and 23:58 hours, from Monday to Sunday.
For example, a Non Transfer schedule which starts at 11 am from Monday to Sunday with
an interval of 30 minutes, would always start at 11 am and would run till 23:30. For
Scheduler, 00:01 is new day and hence it will run this schedule on 11 am the same day.
If the user wants to create a 24 hours working schedule, it is recommended that the user
must create a Schedule starting at 00:10 running at given intervals from that start time from
Monday to Sunday.

Global User Guide
Global Scheduler
10.3 Admin Scheduler

The Global Scheduler window allows the Project Administrator to set-up and manages
schedule extract commands. It is possible to set repeat schedules that run at key points of
the day. Schedules can be set-up to update the parent or child (make changes made in the
Master or Extract viewable in the parent or child), or to transfer items to the parent or child
(relocate the claim to the child or parent so that it can be modified at the remote location).
Schedules are local to the location where the Project Administrator is configuring the
schedules. Therefore a Project Administrator can set-up schedules between itself and any
other location.
The Global Scheduler window is used to create new schedules and display, modify and
delete existing schedules. From the Admin Tool select Data > Global Scheduler.
Schedules are stored in an SQL Database on an SQL Server, when the Project
Administrator clicks on the Global Scheduler menu option a request to the SQL Service is
made. If the SQL Service is not running an error dialogue message will be displayed:
Assuming that the Service is running and the Global Schedule has been configured the
existing schedules are then populated in the Global Scheduler window.
From the AVEVA Administration main menu bar, select Data > Global Scheduler to
display the Global Scheduler window.

Global User Guide
Global Scheduler
The Global Scheduler window is based on a table and allows the Project Administrator to
create and modify scheduled extract commands that can be executed on a regular basis.
The schedules table is used to display and modify schedules. Each row on the table
represents a (separate) schedule. Each column on the table represents a field that can be
set on the schedule.
The columns\schedule fields include: Schedule Name, Location, To, Transfer, Recurrence,
Start Time Repeat and Enabled.
The table is populated with existing (previously saved) schedules on opening the Global
Scheduler window. Existing schedules are displayed in the grid in chronological order
according to their start time. If there are no existing schedules the schedules table is empty.
The Project Administrator can quickly and easily set up schedules. Click + to add a new
schedule (will add a new row to grid) or click - to delete existing schedules.
The Schedule Name is automatically populated, but can be changed. The Schedule
Names are descriptive only and can be duplicates (since it is used for display purposes only
and each schedule has its own internal identifier). For a newly created schedule, the
schedule name is set by default to New Schedule. The selection of the Location and the
To columns are important to setting up the schedule. It is expected that the Project
Administrators will set up the schedule with an idea on what schedule is required, to where
and when. Options available for the Location and the To column drop-downs are only
populated with options that are available in the project. By default the scheduled Location is
set to Required for a new schedule. The Location column drop-down is only populated with
locations that share distributed single extract below a master will be available in the
Location List. The To option only reflects the Parent or Child if there is a Master or child
available remotely. By default the scheduled To option is set to Required for a new
schedule.
The Transfer column determines if the schedule should update the remote Master or Child
with changes made locally, equivalent of doing an EXTRACT FLUSH or REFRESH (option

Global User Guide
Global Scheduler
unchecked) or if it should relocate items so that they can be modified remotely (option
checked). The later will change the claim to be located at the remote location.
The Recurrence column allows the Project Administrator to select what days the schedule
should run on. Select the drop-down menu to display two columns (Recurs On and Day).
To set the schedule to run on a particular day set the Recur On check box on the same row
as the particular day. Setting the schedule to run on a particular day will cause the schedule
to run on that day every week at the specified start time.
The schedule can run on one or more days of the week. For each day the schedule is set to
run an abbreviation (of the name of that day) is added to the Recurrence cell on main Global
Scheduler table. Each abbreviation remains in the cell when the drop down menu is closed.
If the schedule is not set to run on at least one day the schedule is invalid and cannot run
and a warning symbol is displayed in the (blank) recurrence cell.
To set the schedule to run every day of the week the user can check the check box on the
left hand side of the Recurs On header to select all the days.
The Start Time is entered by hand and defines the first time the schedule is run on the days
as defined on the Recurrence column. The start time cell is masked and only accepts a 24
hour time (format).
Note: All schedules will run until midnight.
The Repeat column allows the user to define the time intervals between each execution of
the schedules:

Global User Guide
Global Scheduler
The time is the time interval until the next time the schedule should run, so selecting 30
mins will mean that the schedule will run every half an hour from the Start time (assuming
that the day matched the recurrence). Selecting Never makes the schedule a one off
operation. In this case the schedule will run once, at the start time, on the days defined by
the recurrence.
To define which Databases the schedule applies to, the Project Administrator can select
from a list.
Click on the hyper link Select in the Databases column to display the Database
Configuration window.
The Database Configuration window allows the Project Administrator to add or remove
databases in to or out of the schedule as predefined by the Select hyperlink. Databases not
in the schedule appear in the left column, whereas databases in the schedule appear in the
right. The buttons in the middle allow the Project Administrator to move databases between
the Scheduled and non-scheduled boxes.
The Controlled Extract Workflow only supports extract families with a single Extract below a
Master. When using the Database Configuration window, only extract hierarchies
supporting this are displayed in the available database lists. However, it is possible to create
a third extract below a Master or Extract which will invalidate the schedule. As the scheduler
maintains an independent list of schedules, this results in an invalid extract hierarchy in the
scheduled Extract list. If the user wants to create an extract hierarchy with more than one
extract then any Master or Extract databases must be removed from the scheduler.

Global User Guide
Global Scheduler
The Database Configuration window is only populated with extract hierarchies that are
applicable to the Location and the To options on the Global Scheduler window. So if
Location is set to Cambridge, and To is set to PARENT the Database Configuration
window will only display Master databases that have extracts primary at the current location
and masters primary at Cambridge.
The de-allocated databases will not be removed from the schedules. The purpose of this
allows Project Administrators to do housekeeping operations such as re-config, merge and
clear extracts without worrying about having to reset the Master Databases at the satellites.
The Project Administrators can bring the Database back to the hub, undertake
maintenance, then reallocate the Database back to the satellite.
If the Location is set to Cambridge, but To is set to CHILD the Database Configuration
window will only display Extract databases that are primary Cambridge and Masters that are
primary at the current location.
Note: Only available in Model, so only databases that are of type DESI will only be
displayed in the Database Configuration window.
The Enable column allows the schedule to be enabled or disabled. Select the check box to
allow certain schedules to be disabled if required by the Project Administrator.
Reasons for disabling the schedule:
• Maybe the schedules have been set up, but the location has not been activated yet.
• There are house-keeping operations being undertaken that affect databases at either
location, so the Project Administrator wants to temporarily stop schedules from
running.
When the Project Administrator has set-up and configured all schedule details the
schedules are committed to the scheduler once the Project Administrator clicks Apply (the

Global User Guide
Global Scheduler
OK and + button are temporarily disabled and prevents the user from re-sending the same
data while the previous action is pending) and OK.
Note: The Global Scheduler takes time to initiate the call to the Global Daemon, before the
issued commands appear on the Transaction window, refer to Viewing Command
Transactions for further information.
It is possible for all the schedules to be configured before the Project Administrator clicks
OK or Apply, or clicked between schedule configurations. Click OK or Apply will send a
request to the Global Manager Service that will store the schedules in a SQL database for
the scheduler to activate; this is a client - server request that requires the service to be up.
The service will report an error if it is not possible to contact the service, or there is an
internal error.
The Global Scheduler window validates input as data is entered and will not let the
schedule be created if either the Location or the To option is not set.
Schedules that have been previously stored in the scheduler, but have become invalid due
to project topology changes are highlighted. The conflicting cell is highlighted with a cross
icon. In the example below the schedule has become invalid because the location Leeds
has been deleted. It is safe to have invalid schedules held within the scheduler as these will
fail gracefully.
Fields that are not complete are highlighted with warning icons, as below.

Global User Guide
Global Scheduler
It is not possible to navigate away from the row until both the Location and To have been
set; however it is possible to delete the row.
10.4 Create a New Schedule

To create a new schedule click the (+) button to add a New Schedule row at the bottom of
the table below any existing schedules. The grid row selection can be set to any row before
creating a new schedule. The schedule settings\fields for this new schedule are defined in
this new row:
In this newly appended schedule row the Location and To fields are marked Required and
the Database field is disabled. Until the Location and To fields are defined (i.e. not set to
required) the new schedule is in an unspecified state. Whilst the new schedule is in an
unspecified state the user cannot:
1. Edit\Delete another existing schedule - the row selection is locked to this schedule.
2. Create another new schedule - the Add New Schedule (+) button is disabled, only one
new schedule can be created at a time.
3. Add databases to the schedule (select hyperlink disabled)
4. Save the unspecified schedule

Global User Guide
Global Scheduler
The Location and To fields are mandatory but don't necessarily have to be set and defined
before the other fields in the Schedule. The user can delete the unspecified schedule by
clicking the delete (- minus) button. Once the Location and To have been defined, the
schedule is in a specified state and the user can do any or all of the above list (1-3).
New unsaved schedules (i.e. schedules created since the last save) will be marked with a
blue asterisk in the row selector and have a row tool-tip of Unsaved schedule. The
Location and To can be changed for an unsaved schedule. However if databases are
allocated to the schedule a Confirm message window is displayed, the user needs to
confirm if it wants to continue and make this change and consequently reset the DB list.
When the schedule is saved (i.e. committed to the database) the blue asterisk is removed
and the Location and To fields are locked for this schedule. If the Location and To fields
need to be changed for a (saved) schedule, the schedule (in question) must be deleted and
recreated and the Location and To reset.
Any number of new schedules can be created in a session, since the last save provided
each is specified after it's created (i.e. the Location and To is set for each of them).
10.5 Delete a Schedule

To delete an existing schedule select it's schedule row (by clicking on the row selector
adjacent to the row on the right hand side of the grid) in the grid and click the remove (-
minus) button. The remove (-) button is only enabled when a row in the schedule grid is
selected.
Note: If an unspecified schedule exists no other schedule can be deleted (as the row
selection cannot be changed) until either the unspecified schedule is specified or is
deleted).
Only one schedule can be deleted at a time but any number of schedules can be deleted in
a session (since the last save or whilst the Global Scheduler window is open). After
deleting a schedule the schedule above the deleted schedule is selected in the table.
Deleting a schedule from the table does not remove it from the database, in order for the
deleted schedules to be removed from the database the (deleted) changes have to be
saved. If schedules are not removed from the database (i.e. the deleted changes are not
saved) the deleted schedules will re-appear on re-opening the Global Scheduler window.
There is no confirmation box for the user to confirm the deletion of a schedule to retrieve a
schedule that was not intended to be deleted (before the user clicks OK and Apply) click
Cancel on the Global Scheduler window and re-open it.

Global User Guide
Global Scheduler

Global User Guide
Index
A creation . . . . . . . . . . . . . . . . . . . . . . 3:1
de-allocation . . . . . . . . . . . . . . . . . . 5:8
Admin deleting . . . . . . . . . . . . . . . . . . . . . 5:10
Elements form . . . . . . . . . . . . . . . . . 4:2 foreign . . . . . . . . . . . . . . . . . . . . . . . 3:8
Admin daemon . . . . . . . . . 2:1, 3:1, 3:5, 4:5 merging sessions . . . . . . . . . . . 3:7, 5:17
diagnostics . . . . . . . . . . . . . . . . . . . . 8:2 non-propagating . . . . . . . . . . . . 3:8, 5:10
progress messages . . . . . . . . . . . . . 8:2 scratch . . . . . . . . . . . . . . . . . . . . . . . 3:8
stopping . . . . . . . . . . . . . . . . . . . . . 4:13 updates . . . . . . . . . . . . . . . . . . . . . . 3:6
Allocation . . . . . . . . . . . . . . . . 4:9, 4:19, 5:2 De-allocation . . . . . . . . . . . . . . . . . . . . . 5:8
of databases . . . . . . . . . . . . . . . . . . . 3:8 Deleting
Allocation order . . . . . . . . . . . . . . . . . . . . 5:6 Databases . . . . . . . . . . . . . . . . . . . 5:10
Ancestor (Location) . . . . . . . . . . . . . . . . . 3:3 Locations . . . . . . . . . . . . . . . . . . . . 5:14
Area number . . . . . . . . . . . . . . . . . . . . . 5:10 Descendant (Location) . . . . . . . . . . . . . . 3:3
DRAW . . . . . . . . . . . . . . . . . . . . . . . . . . 3:9
C
Child (Location) . . . . . . . . . . . . . . . . . . . . 3:3 E
Command Transactions . . . . . . . . . . . . . 5:6 Environment variables . . . . . . . . . . . . . . 4:7
Commands . . . . . . . . . . . . . . . . . . . . . . . 7:1
managing . . . . . . . . . . . . . . . . . 7:3, 7:6
Communications
F
networks . . . . . . . . . . . . . . . . . . . . . . 3:3 Foreign Databases . . . . . . . . . . . . . . . . . 3:8
D G
Daemon . . . . . . . . . . . . . . . . . . 2:1, 3:1, 3:5 Global . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1
Data Access Control . . . . . . . . . . . . . . . . 5:1 Global Daemon
Data integrity checking . . . . . . . . . . . . . 5:22 running check . . . . . . . . . . . . . . . . 4:16
Data recovery . . . . . . . . . . . . . . . . . . . . . 6:3 service configuration . . . . . . . . . . . 4:15
remote . . . . . . . . . . . . . . . . . . . . . . 5:21 Groups . . . . . . . . . . . . . . . . . . . . . . . . . 5:14
Database . . . . . . . . . . . . . . . . . . . . . . . . . 3:2 root . . . . . . . . . . . . . . . . . . . . . . . . . 5:14
allocation . . . . . .3:1, 3:8, 4:9, 4:19, 5:2
area . . . . . . . . . . . . . . . . . . . . . . . . 5:10
H
backtracking . . . . . . . . . . . . . . . . . . . 3:7
compaction . . . . . . . . . . . . . . . . . . . . 3:7 Hostname . . . . . . . . . . . . . . . . . . . . . . . . 4:5
© Copyright 1974 to current year. Index page i 12 Series

Global User Guide
Hub P
location . . . . . . . . . . . . . . . . . . . . . . . 4:3
Hub Location Parent
changing . . . . . . . . . . . . . . . . . . . . . 5:12 (Location) . . . . . . . . . . . . . . . . . . 3:3, 4:5
recovering . . . . . . . . . . . . . . . . . . . . 5:13 Pending file . . . . . . . . . . . . . . . . . . . . . . 3:6
Picture files . . . . . . . . . . . . . . . . . . . 3:9, 5:10
Plot files . . . . . . . . . . . . . . . . . . . . . . . . . 3:9
I Primary Location
Initialising Locations . . . . . . . . . . . . . . . 4:16 recovering . . . . . . . . . . . . . . . . . . . 5:11
Installing Project Project
at Satellite . . . . . . . . . . . . . . . . . . . . 4:10 making . . . . . . . . . . . . . . . . . . . . . . . 4:1
Integrity checking . . . . . . . . . . . . . . . . . 5:22 Replication . . . . . . . . . . . . . . . . . . . 5:15
Inter-db macros . . . . . . . . . . . . . . . . . . . 6:10 Projects . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
ISODRAFT files . . . . . . . . . . . . . . . . . . . 3:9 Propagation . . . . . . . . . . . . . . . . . . . 3:1, 3:6
Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1 non-propagating files . . . . . . . . . . . 5:10
remote . . . . . . . . . . . . . . . . . . . . . . 5:18 Propagation order . . . . . . . . . . . . . . . . . 5:6
L R
Location . . . . . . . . . . . . . . . . . . . . . . . . . 3:1 Recovering
code . . . . . . . . . . . . . . . . . . . . . . . . . 4:4 Hub Location . . . . . . . . . . . . . . . . . 5:13
creating . . . . . . . . . . . . . . . . . . . . . . . 4:7 Primary Location . . . . . . . . . . . . . . 5:11
deleting . . . . . . . . . . . . . . . . . . . . . . 5:14 Transaction Database . . . . . . . . . . . 6:5
description . . . . . . . . . . . . . . . . . . . . 4:4 Recovery of data . . . . . . . . . . . . . . . . . . 6:3
Groups . . . . . . . . . . . . . . . . . . 3:4, 5:14 remote . . . . . . . . . . . . . . . . . . . . . . 5:21
id . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:4 Remote operations . . . . . . . . . . . . . . . . 5:15
initialising . . . . . . . . . . . . . . . . . . . . 4:16 Replication . . . . . . . . . . . . . . . . . . . . . . 5:15
name . . . . . . . . . . . . . . . . . . . . . . . . 4:4 Root
off-line . . . . . . . . . . . . . . . . . . . . 3:4, 9:1 of Location Group . . . . . . . . . . . . . 5:14
Primary . . . . . . . . . . . . . . . . . . 3:1, 4:17
Secondary . . . . . . . . . . . . . . . 3:1, 4:17 S
Location Groups
root . . . . . . . . . . . . . . . . . . . . . . . . . 5:14 Satellites . . . . . . . . . . . . . . . . . . . . . . . . 4:10
Locking . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1 Scratch
remote . . . . . . . . . . . . . . . . . . . . . . 5:18 databases . . . . . . . . . . . . . . . . . . . . 3:8
files . . . . . . . . . . . . . . . . . . . . . . . . 5:10
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 3:6
M Synchronisation
MDBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1 (see also updates) . . . . . . . . . . . . . . 6:2
Merging/Purging a Transaction Database 7:7 System Database . . . . . . . . . . . . . . . . . . 3:2
Messaging . . . . . . . . . . . . . . . . . . . . . . . . 6:7
Monitoring commands . . . . . . . . . . . . . . . 7:1 T
Transaction
N database . . . . . . . . . . . . . . . . . . . . . 3:6
Networks Event Timings . . . . . . . . . . . . . . . . . 7:6
communications . . . . . . . . . . . . . . . . 3:3 Transaction Messages
Non-propagating files . . . . . . . . . . 3:8, 5:10 managing . . . . . . . . . . . . . . . . . . 7:3, 7:6
status . . . . . . . . . . . . . . . . . . . . . . . . 7:3
Transfer Directory
O
off-line Locations . . . . . . . . . . . . . . . 9:1
Off-line Locations . . . . . . . . . . . . . . . . . . 9:1 Transfer directory . . . . . . . . . . . . . . . . . . 4:7
© Copyright 1974 to current year. Index page ii 12 Series

Global User Guide
U
Update events . . . . . . . . . . . . . . . . 3:7, 4:21
Updates . . . . . . . . . . . . . . . . . . . . . . . . . . 3:6
(see also synchronisation) . . . . . . . . 6:1
unscheduled . . . . . . . . . . . . . . . . . . . 6:1
Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
W
Working files . . . . . . . . . . . . . . . . . . . . . 5:10
© Copyright 1974 to current year. Index page iii 12 Series


Global User Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Global User Guide

Uploaded by

Copyright:

Available Formats

Global User Guide

AVEVA Solutions Limited

Date Version Comments / Remarks

Global User Guide

Global User Guide

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

© Copyright 1974 to current year. i 12 Series

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

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

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

© Copyright 1974 to current year. ii 12 Series

Database Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:2

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

© Copyright 1974 to current year. iii 12 Series

Recovering Secondary Databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:4

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

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

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

Global Scheduler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:1

© Copyright 1974 to current year. iv 12 Series

Admin Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:4

© Copyright 1974 to current year. v 12 Series

© Copyright 1974 to current year. vi 12 Series

1.1 Who Should Read This Manual

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 is a step-by-step description of how to make a Global project,

© Copyright 1974 to current year. 1:1 12 Series

Monitoring Command describes how to monitor the progress of Global commands

Off-line Locations describes how to set up and administer the communications

1.3 Other Documentation

© Copyright 1974 to current year. 1:2 12 Series

2.1 Communications Between Locations

© Copyright 1974 to current year. 2:1 12 Series

© Copyright 1974 to current year. 2:2 12 Series

3.1 What is a Global Project?

3.2 How Databases are Handled

© Copyright 1974 to current year. 3:1 12 Series

3.3 System and Global Databases

© Copyright 1974 to current year. 3:2 12 Series

3.4 Networks and Communication Links

Figure 3:1. Examples of tree structures for locations

© Copyright 1974 to current year. 3:3 12 Series

3.4.1 Off-line Locations

3.4.2 Location Groups

Using groups, the following network configurations can be supported.

© Copyright 1974 to current year. 3:4 12 Series

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

3.5 Global Daemons

3.5.1 How the Global Database is Updated

© Copyright 1974 to current year. 3:5 12 Series

It is important to be aware that:

3.5.2 The Transaction Database and the Pending File

3.5.3 How Database Updates are Propagated

© Copyright 1974 to current year. 3:6 12 Series

Session 0 Session 0 Session 0 Session 0

Location AAA Hub Location AAA Hub

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

3.6 What Happens if a Communication Link Fails

© Copyright 1974 to current year. 3:7 12 Series

3.7 Database Allocation

3.8 Propagating and Non-propagating Files