PDGRGP PDF

Running Global Projects
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.
Revision Sheet
Date Version Comments / Remarks

September 2011 12.1.1 Issued
January 2012 Copyright added to all pages.
January 2013 12.1.SP3 Added new sub section 10.3.1 Propagation of Databases of
access-type update
Contents Page

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
Global Mode of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1
Global Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
Location of the Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
Daemon Access Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
Daemon Buffer Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
Daemon Diagnostics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1

Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:2
Diagnostic Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:2
Database Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:1

Allocating Databases to Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:1
Checking Database Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:1
De-allocating Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:2
De-allocating a Database from a Location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:3
admnew Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:3
Using Areas in Global. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:4
Merging Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1

Global Merging on Non-Extract Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1
© Copyright 1974 to current year. i 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
Procedure for Merging Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:2

Merging Extract Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:2
Transaction Audit Trail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1

Writing to the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1
Reading from the Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1
Program Initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1
Reading Command Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:2
Following the Audit Trail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:2
As seen from the TRINCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:2
As seen from the TROUCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:3
As seen from the TROPER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:4
Audit Trail Dates and Counts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:5
Cancelled Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:7
Processing of Results and Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:7
Transaction Success and Failure Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:7
Scheduled Updates - Successes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:8
Scheduled Update - Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:9
Failed File Copies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:11
Reasons Other ADMIN Commands Can Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:12
Automatic Merging and Purging of a Transaction Database . . . . . . . . . . . . . . 7:13
Pending File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:1

Changing the Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:1
Preparation for Changing the Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:1
Recovering from Change Hub Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:2
Updates and Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:1

Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:1
Manual Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:1
Update and Timing Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:2
Propagation of Databases of Access-Type Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:2
Propagation of Picture and Neutral Format Files . . . . . . . . . . . . . . . . . . . . . . . 10:2
Propagation of Marine Drawing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:4
Propagation of Inter-Database Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:4
Propagation of Linked Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:5
© Copyright 1974 to current year. ii 12 Series

Update Timings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:7

Transfer of Other Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:7
Reverse Propagation Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:9
Deleting Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11:1

Database Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:1
Recovering Secondary Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:1
Recovering Primary Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:2
Recovering Database Primary Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:2
Recovering the Global Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:2
Transaction Database Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:3
Renewing the Transaction Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:3
Merging the Transaction Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:3
Reconfiguring the Transaction Database at a Satellite . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:4
Recommendations for Reconfiguring (User dBs) . . . . . . . . . . . . . 13:1

Copying Global Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14:1
Backing Up Global Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15:1
Using Extracts with Global Projects . . . . . . . . . . . . . . . . . . . . . . . . 16:1
Using Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:1
Extract Families . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:1
Querying Extract Families . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:2
Creating Master and Extract Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:3
Creating Master Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:3
Creating Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:3
Creating Working Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:5
Extract Numbers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:6
Reference Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:6
Setting up an Extract Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:7
Using DACs with Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:7
Using Extracts in MODEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:8
Managing Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:9
User Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:9
Extract Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:9
Command Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:9
© Copyright 1974 to current year. iii 12 Series

Extract Flush Commands Failing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:11

Relationship between Extract and User Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:11
How to Find Out What You Can Claim. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:11
Flushing Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:13
Releasing Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:14
Issuing Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:14
Dropping Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:14
Refreshing an Extract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:14
Partial Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:15
Extract Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:15
Merging Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:16
Deleting a Database that owns Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:16
Variant Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:18
Reasons Claims and Flushes can Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:18
Off-line Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17:1

Working Practices with Off-line Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17:1
Firewall Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18:1

WCF Port Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18:1
Limiting Ports Used with RPC Communication . . . . . . . . . . . . . . . . . . . . . . . . 18:1
Suggested Housekeeping Guidelines for Projects . . . . . . . . . . . . 19:1

Dice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:1
Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:3
Update Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:3
Timing of Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:3
Checking Locations are Aligned. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:4
Change Primary - Repair Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:5
Risks of Aligning Databases Across Locations by File Copying . . . . . . . . . . . . . . . . . . . . 19:5
Flushing/Issuing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:6
Transaction Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:6
Daemon Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:7
admnew Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:7
Session Management - Merging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:7
Database File Locks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:8
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:8
Avoiding Random File locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:8
© Copyright 1974 to current year. iv 12 Series

Locating and Closing Locked and/or Open Database Files . . . . . . . . . . . . . . . . . . . . . . . . 19:8

Distributed Extract Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:10
Project Administration Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:10
ADMIN Lead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:11
Discipline SME’s (Subject Matter Experts). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:11
Global Satellite Co-ordinator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:11
Project Setup Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A:1

Recovery from Reverse Propagation Errors . . . . . . . . . . . . . . . . . .B:1
Background - Propagation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B:1
Identifying the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B:2
Querying Database Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B:2
Automating Checks For Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B:4
Using Global to Distribute Catalogue Data. . . . . . . . . . . . . . . . . . . .C:1

Example Macro for Collecting and Deleting Old Commands . . . . .D:1
© Copyright 1974 to current year. v 12 Series

© Copyright 1974 to current year. vi 12 Series

Introduction
1 Introduction
This document proposes a set of guidelines for the effective use of the AVEVA Global
product. The guidelines result from current working experience and may be amended in the
light of future experience. Global manages a project distributed over several different
geographical locations connected by a Wide Area Network (for example the Internet) and so
presents special situations for the administrator and engineering user, which the guidelines
address.
Note: References to 'Windows' in this document mean MS Windows 2000 or MS Windows

XP.
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.
© Copyright 1974 to current year. 1:1 12 Series

Introduction

Global Mode of Operation
2 Global Mode of Operation
In standard projects, 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, remote commands 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 in Global is to prevent a slow long-
transaction command from blocking the user. Its disadvantage is that the user needs to work
in a new way to exploit this parallel nature of Global.
If a remote command traversing the Global network becomes held up at a particular location
(for example due to a comms line fault) then, for most commands, the command is placed in
a transaction database at that location for later processing. A small number of commands,
known as ‘kernel’ commands, bypass the transaction database and are stored in a pending
file for later processing. The use of the transaction database and the pending file means
that commands are guaranteed to complete, but some commands may not succeed. Some
may roll back, while others may just fail.
For further information about the transaction database, see Transaction Audit Trail, and
Transaction Database Management.

Global Mode of Operation

Global Daemon
3 Global Daemon
The Global daemon (sometimes referred to as the ADMIN daemon) is supplied with the
Global product, in the default install folder.
During installation the user can choose between an RPC or WCF version of Global. RPC is
part of the standard Windows software, and no additional software has to be installed. The
WCF version has some dependencies and these are described in the Global WCF
Configuration Guide. The information contained in this guide applies equally to both RPC
and WCF versions of the Global daemon.
Installing the Global daemon is described in the Global Installation Guide, configuring and
starting the daemon is described in the Global User Guide.
There must be one Global daemon running for each Project at a Location.
Note: The user must plan which protocol to use before implementing a Global project,
including firewall and security considerations.
Important: An RPC Global daemon cannot detect whether a WCF Global daemon is
already running for that project.
3.1 Location of the Daemon

We recommend that the daemon is run on the file server, thus reducing the risk of it being
accidentally stopped by a user, which could result in missed updates.
The Global 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. When the
daemon is run as a service, it must be run on the file server.
3.2 Daemon Access Rights

To enable updates to function correctly between locations, the user who starts the daemon
must have sufficient access rights to all project databases at the current location. For
example, a daemon running at Location A will need to have Read/Write access to all of the
databases at Location A.
3.3 Daemon Buffer Size

Dabacon buffer size can be set in the GLOBALDAEMON module definition. The default
value is 2560000 but the Administrator may specify a larger or smaller value than this. Note

Global Daemon
that the buffer size should be at least this value in projects where distributed Extracts are
being used.
• The Dabacon buffer size can be changed by using the MODULE command. See the
Administrator Command Reference Manual for details.

Daemon Diagnostics
4 Daemon Diagnostics
The Global daemon has the following types of diagnostic output:

• Tracing.
• Logging.
4.1 Tracing
Tracing can be switched on when the daemon is started. If running the Global daemon as a
service, add a line to the startup batch file singleds.bat to set the environment variable
DEBUG_ADMIND as follows:
DEBUG_ADMIND=1023
If the Global daemon in not being used as a service, set DEBUG_ADMIND from the
command line.
The value of the DEBUG_ADMIND variable determines the type of activities that are traced:
0 = Not used
1 = Not used
2 = Trace
4 = Remote Procedure Calls
8 = Thread Library
16 = Systems DB Access
32 = Dabacon Thread
64 = Event Loop Thread
128 = Operation Thread
256 = Trans DB I/O
512 = Not used
1024 = Not used
2048 = Dabacon Detail
These values are bit settings, so to trace a combination of activities, add the above values
together. For example, to trace Systems DB access and the Event Loop thread only, set
DEBUG_ADMIND as follows:

Daemon Diagnostics
DEBUG_ADMIND=80
To enable tracing for all activities, set the DEBUG_ADMIND value to 3071. A useful level of
tracing for tracking commands is 896.
Full tracing can be verbose and fill disk space rapidly, the recommended value of 896 allows
the administrator to gain an idea of the current number of commands running through the
system.
This may help when bringing down a daemon at a particular location. Further tracing may be
required when investigating a particular problem.
4.2 Logging
It is beneficial to have the Daemon log setting activated for troubleshooting purposes as well
as helping the System Administrator to know how the Global daemons are functioning. We
can activate the diagnostics by configuring the Global ADMIN comms log.
The Global ADMIN comms log is activated from Daemon>Daemon Settings. This will
display the Local Daemon Settings window. In the appropriate text boxes, enter the
Diagnostic Logfile name, the Diagnostic Level (see below), and finally Enable the
Diagnostic Logging using the drop-down list.
Note: If using an environment variable in the log file path, it must be defined in the daemon
script or in the window from which the daemon was started.
4.2.1 Diagnostic Level

The number to be entered is the sum of the code numbers for the individual requirements
shown below:
0 = None
1 = Received summary
2 = Received detail
4 = Send summary
8 = Send detail
16 = Dabacon thread summary
32 = Dabacon thread detail
64 = Propagation thread summary

Daemon Diagnostics
0 = None
128 = Propagation thread detail
255 = Full logging.
Alternatively, log values can be selected by clicking the Define button.
The log files can be sent to the administering location at regular intervals.
The log file will get bigger over time. If the log record needs to be kept, start a new file, move
the log file to another directory.
The daemon checks for the log file location every 15 minutes. It will keep writing to the
moved log file until it checks the log file location and finds it has moved, and then a new log
file will be generated.
Note: Logging does not capture the same data as tracing, for full debugging purposes the
trace facility provides much more comprehensive internal diagnostics.

Daemon Diagnostics

Database Allocation
5 Database Allocation
5.1 Allocating Databases to Locations

Before allocating databases, make sure that both daemons are running by selecting
Query > Global States > Communications or by issuing a Ping command.
ALLOCATE commands can be given in sequence without waiting for the first allocate to
finish. However, the same Allocate command should not be done twice, unless confident
that the allocation has failed and that there is no entry in the transaction databases at either
of the locations affected by the allocation.
When databases have been allocated to a location, databases cannot be added to MDBs
until all allocations have been completed, so it is advisable to check the progress of
allocations first.
It is advisable to use macro input for long lists of database allocations; for example:
ALLOCATE <db name> PRIMARY at /Satellite
ALLOCATE <db name> at /Satellite
…and so on for each allocation.
This will most likely be the case when the Global project is initially created.
Note: Once all allocations have been committed, it is worth checking that all commands are
complete, whether the command has been executed through the GUI, or as a
manual command. This is described in the next section.
If a de-allocation is in progress (see the DEALLOCATION command), then the allocation

will stall until the de-allocation is complete before commencing.
5.2 Checking Database Allocations

Once database allocation has finished, check that the commands have been completed. Do
this by selecting DB & Extracts from the Admin Elements window, which displays a list of all
the allocated databases at the location where dBs are being allocated. Alternatively, check
that the allocation has completed successfully from the command line by listing the
elements under the DBALL (the allocation list; see below), under the LOC element, at both
the Hub and the Satellite locations. Until all databases are physically allocated to the
location, the DBALL will not own the database allocation.
The allocation process may take some time if there is a slow link between Hub and Satellite
and/or if database sizes are large.

Database Allocation
A Get Work must be done prior to listing the DBALL, (carry on doing a Get Work to see
when the databases have been allocated). Allocation is successful when the DBALL list
contains all of the databases allocated.
getwork
/Satellite - Navigate to the location (LOC element)
1 - Go to the first member, i.e. DBALL
q mem - list the members, i.e. allocated databases
5.3 De-allocating Databases

The same principles for allocating databases, as described above, apply to de-allocating
databases.
If users are reading a database at any satellite location and it is de-allocated at that location
by the hub while it is being read, then the database(s) de-allocated will not immediately be
deleted from the satellite locations.
The command will be stalled in the transaction database and, once all users at the location
exit their session, the database(s) will be de-allocated and the database files deleted.
Note: Only secondary databases can be de-allocated. If a database is primary at a satellite,

first make it secondary, then de-allocate it. If changing a database from primary to
secondary while a user is reading/writing to it, the user will be able to write to the
database until such a time as that user changes modules. A dB does not need to be
primary at the HUB, just as long as it is not primary at the location where it is being
de-allocated.

Database Allocation
5.4 De-allocating a Database from a Location
5.4.1 admnew Files

.admnew files are created when the whole database needs to be propagated. This may
occur:
• Whenever a database is allocated to a location. The database is copied from the hub to
the new location by the Global daemon. As the file is copied over the network
connection, a file named
prjnnnn.admnew
is created. Once copying is complete, this file is renamed automatically to
prjnnn

Database Allocation
For example: abc0001.admnew is created while copying, and it is renamed to

abc0001 once copying is complete.
• Whenever a primary database is merged. The next update will force the entire
database to be propagated.
• If the RECOVER command is used to recover a database from a specified location
.admnew files are self contained by the system, there should be no reason to delete
them, except in extreme cases. If the daemon is running continuously and a Copy dB
operation fails then the system should tidy up. Normally .admnew files are retained for
later use. However, if the daemon dies (such as in a power-cut) during the process this
may result in an invalid .admnew file. In this case the file should be removed from the
operating system to avoid possible problems on a repeat operation.
In the case of a copy after a database has been merged, it may not be possible for the
.admnew file to be renamed immediately. This will happen:
• If there are READERS of the database -users are accessing an MDB which contains
the database (even if they are only in MONITOR). In this case Global will not attempt to
rename the .admnew file until all such users have exited or switched to an MDB which
does not include the database. Once all such users have exited, the copy will normally
succeed.
• If the database is locked by a ‘Dead’ user - a session for a user which has been
expunged. In this case Global attempts to rename the .admnew file, but it fails.
To resolve the second situation, one of the following must be done: either
• Make sure that the sessions for all ‘dead’ users have been killed. Also make sure that
no foreign projects are reading this database; or
• Use the NET FILE command in a ‘cmd’ window (or a suitable third party tool) to identify
network access to the file, and close it.
If the project is not used as a foreign project, there is an additional alternative. The
Overwrite DB Users flag - the attribute LCPOVW of the LOC element - for a location
controls whether a ‘locked’ file may be overwritten. If this attribute is set TRUE and
there are no database READERS in the project, then Global will overwrite the ‘locked’
file by the .admnew file.
Note: This should not be done if other projects include this database as a foreign project,
since these are valid READERS that are not recorded in the session data for the
Global project.
Overwriting of locked databases may be enabled by using the ‘MODIFY’ dialogue for the
location on the Admin Elements window to enable Overwriting, or by setting LCPOVW
TRUE for the appropriate LOC element on the command-line.
See also Database File Locks.
5.4.2 Using Areas in Global

Areas are available within Global and can be used in the same way as non-Global projects.
However for the daemon to manage updates and Global functionality the area environment
variables must be set before starting the daemon. If the daemon is run as a service then the
environment variables must be set within the kick-off batch script.

Merging Databases
6 Merging Databases
When setting up a project in a Global environment, the user is likely to create many
sessions in the Global database. This is because when ADMIN issues a Daemon
command, it first does a SAVEWORK to give the Daemon an up-to-date view of the Global
database. The Daemon also may add sessions to the Global database.
We recommend that the user should merge changes for the Global database and possibly
the system database after setting up a Global project. This should also be done after making
significant changes to the project setup.
6.1 Global Merging on Non-Extract Databases

Take care when merging project databases. Databases can only be merged at their primary
locations. It is important to note that when a project database is merged, the database
session will effectively be lost. Thus the ability for Global to send only session changes is
lost too.
It is therefore recommended to use the Global Merge command (syntax REMOTE MERGE
(or select Remote > Global Change Management > Global Merge Changes from the
ADMIN menu bar) to synchronise and merge the database at all secondary locations
(unless the database is non-propagating). This prevents propagation of the entire database
on the next update.
If there are any users in a database at its primary location, the database cannot be merged.
The Global Merge merges the database at secondary locations after it has been merged at
the primary location in order to prevent unnecessary copying of the entire database when it
is next updated.
The user is advised to stop scheduled updates and avoid adhoc updates when using Global
Merge. If scheduled updates are left in place, then unnecessary copying of entire databases
will be undertaken. There is also a danger of reverse propagation from secondary to primary
location, with the result that changes made by users at the primary location would be lost.
Note that database extracts which own other extracts cannot be merged using REMOTE
MERGE. See Merging Extract Databases.

Merging Databases
6.1.1 Procedure for Merging Changes
6.2 Merging Extract Databases

The REMOTE MERGE command cannot be used on extract databases if they own other
extracts. Instead, ADMIN must be used to merge these. The extract to be merged and all its
immediate children must be primary at the same location. This is because the child
extracts contain references to sessions in the owning extract.
Procedure to merge an individual extract database:
• Select a suitable time to execute the merge, and make sure that all users have left the
project
• Use CHANGE PRIMARY to bring all its immediate child extracts to the primary location
of the extract being merged
• MERGE the database

Merging Databases
• Use CHANGE PRIMARY to return the child extracts back to their original primary
location.
• Optionally, the databases could be copied (by ftp or similar) to all secondary locations
manually after the MERGE (and before the second set of CHANGE PRIMARY
commands). This avoids the need for the next Update to copy the entire file.
Normally merging would be carried out on the entire extract hierarchy at the project
Hub. However if an extract database owns working extracts, it must be merged at its
original primary location, since the working extract files only exist at that location.

Merging Databases

Transaction Audit Trail
7 Transaction Audit Trail
The Global Daemon stores most of the commands that it is asked to perform in its
transaction database. Kernel commands (high level control commands) are stored in the
pending file until complete.
The transaction database can be navigated using the command line in ADMIN using
standard navigation commands. The information in the database will give the system
administrator more information about the progress of commands, and details of why
commands have failed. Much of this information is available through the user interface but
this section is included to instruct the system administrator on how to interpret the
transaction database and the audit trail information stored there.
Each Location in the Global Project has a Global Daemon (also known as ADMIN Daemon)
running. The Daemons at each location communicate and co-operate with each other to
perform actions that a user at a particular site wishes to effect: for example to allocate
databases (from ADMIN), or to claim elements (say from MODEL).
7.1 Writing to the Database

The Daemon writes a persisted copy of each input command to the database as soon as it
is received, and each operation and output command is written as soon as all have been
successfully created at both the create operations and create post operations stage.
State changes for input and output commands, and operations are written immediately after
the state change. However optimisation may reduce the number of changes that are
actually committed to the database.
All results from an operation are written after the operation completes, and from an output
command as soon as they have been received from the location to which it was sent and
which has now replied.
Messages are written only as they are received, AT THE ORIGINATING location only.
Success and failures may also be visible at other locations involved in the command.
7.2 Reading from the Database

The Daemon reads from the transaction database for just two purposes:
7.2.1 Program Initialisation

The program reads out of the database all input commands not in a final state (processed,
timed out, cancelled) and all the owned operations and output commands and starts

progressing these commands. Only unfinished commands will be read. All others will be
ignored and not validated for errors.
If there are any errors found in reading the database, the daemon will not start. It will then be
necessary to provide a (probably) empty database so that the daemon will start from fresh
and not progress any previously running commands.
7.2.2 Reading Command Data

Whenever command data is needed, such as to generate an output command to send on,
this data is read from the database. This is the only time that data is read from the database,
except at boot up, and is done purely as an optimisation to limit the amount of memory used
by the daemon.
The storage of the information in the database has the additional advantages:
• It provides the user with information on the progress of his commands, allowing him to
browse the messages that have been received and persisted in this database.
• It provides the administrator with an audit trail to determine if and where a problem has
occurred.
• It provides other modules of the base product with a store to deposit local
administration information such as element claims. However, these commands are
totally ignored by the daemon.
7.3 Following the Audit Trail

The following section refers to elements within the Transaction Database. For more detail
about Transaction Database Elements refer to the Administrator Command Reference
Manual.
7.3.1 As seen from the TRINCO

A TRINCO is created when an input command is received. It has a creation date (DATECR)
an initial state (INCSTA) of ‘Received’, and a command type TRCNUM.
If the command came from the user, (or from TIMEDUPDATES) then the command UID
(COMUID) is set to a null reference. Otherwise it will be the reference of the output
command (TROUCO) that sent the command. If this is from another location it is an
unknown reference as it is in another transaction database that is not in the current MDB
and so cannot be navigated to.
The originating location of the command (where a user first issued it) is ORILOC. The
location that sent the command to this location is PRVLOC. And the destination location to
which it is eventually heading is DESLOC. Normally, commands are passed from location to
location until the destination is reached where operations take place. For some commands,
the operations take place at the ORILOC and DESLOC is used as a location to which to
pass on some other commands. It is not obvious which commands are exceptions to the
normal rule.
If INCSTA = ‘Acknowledged” then an acknowledgement has gone to the sender of the
command. This is only relevant if the sender was a TROUCO and not a base product user.
If the state INCSTA = ‘Ready’ then the input command has created its operations
successfully and TROPERs and/or TROUCOs will exist.
If there was a failure in the create processes the INCSTA may be ‘Stalled’ and no operations
will exist. After waiting for the standard time the command will try again. Alternatively this

failure can terminate the TRINCO. Its TRPASS will be set to FALSE, its state will be
“Complete” or a later state, and it may own a TRMLST/TRMESS and perhaps a TRFAIL but
no TROPERs or TROUCOs. Input commands can be given a delayed start time (EXTIME)
after which operations will be generated. It will wait in the “Waiting” state until this time has
passed. This stay of execution will persist until EXTIME has expired, even if this is a longer
period than the Time out.
The TRINCO stays in ‘Ready’ state for as long as all its operation and output commands
take to complete. Once the TRINCO has been set to ready the command cannot time out
until all operations have also timed out.
When all member operations and output commands have completed INCSTA is set to
“Complete”. All failures and successes generated by them are collected together and
handed on to the sending TROUCO (which stores them). The success state of the
command (TRPASS) is set to true if all operations have succeeded. INCSTA is now at
“Replied”.
Once a reply acknowledgement has been received back from the previous location, INCSTA
is set to ”Processed” and no more actions will take place.
There are other terminating conditions of a TRINCO; “Timed Out” means that the command
did not manage to start before either its end time was reached, or the number of retries
allowed was exceeded. It will not own any TROUCOs or TROPERs.
The state is set to “Cancelled” if the command is cancelled before any significant action took
place. Owned TROUCOs and TROPERs may be set to cancelled if they have not yet
started work: subsequent operations that depend on them will be set to “Redundant”.
7.3.2 As seen from the TROUCO

Output commands may be created when input commands create their operations and
possibly again when post operations are generated. These TROUCOs have ORILOC set to
the current site, DESLOC the ultimate processing destination of the command and are sent
to NXTARL, the next destination en route. The command type is the TRCNUM attribute.
If the current location is not the destination of the incoming TRINCO then a TROUCO is
created to manage the progression of the command to its destination when all other (if any)
operations and output commands on which it is dependent have completed. This TROUCO
is a duplicate of the owning TRINCO and when it is passed on its ORILOC is that of its
owning TRINCO.
TROUCOs store the progress of the communication of the command with the location to
which it is sent (NXTARL) and the reply.
OUTSTA is the state of processing of a TROUCO. Its value is “Waiting” until the command is
ready for processing. This may be delayed because of dependency on other operations or
output commands. These dependencies are stored in DEPCOU, DEPEND and DEPTYP
attributes - the number of dependencies, the elements depended on, and whether it is on
success or failure.
When all previous commands and operations on which the TROUCO is dependent have
completed, and when the condition of the dependencies are met the TROUCO’s state
changes to “Ready”. After this point the command is sent to its target location and its state is
set to “Sent”. If the sending fails the TROUCO is “Stalled” and remains so until the time
between retries (WAITIM) for that location is passed when it goes back to “Ready” again.
The receiving location must acknowledge the command (OUTSTA = “Acknowledged”. The
acknowledgement is sent with the dbReference of the TRINCO at the receiving location that

has been created to store the command. This is stored in the TROUCO’s CMREF attribute.
For remote locations this will usually be an unknown reference since the specific transaction
database is not visible. It can be used to track the command down the chain of locations if
the administrator can see all the databases.
When a reply is received OUTSTA becomes “Replied”. Any reply data is stored under
TRFLST and TRSLST elements and the TRPASS attribute and OUTSTA goes to
“Processed”.
TROUCOs can terminate by timing out if they fail to send in the lifetime prescribed (“Timed
Out”. They may never be sent if dependencies are not met, in which case they terminate as
“Redundant”.
7.3.3 As seen from the TROPER

Operations are created during the create operations process and possibly again when post
operations are generated. Operation information is stored in TROPER elements. This is
used to execute an operation at a location, to progress the operation and store any results,
errors, messages it may generate.
It is only operations that actually do anything in the daemon, input and output commands
(TRINCOs and TROUCOs) are just the means of marshalling instructions between users
and locations, and between locations. Extra commands may be generated, but in the end it
is the operations that are created at locations that do the work.
The operation type is the TRONUM attribute.
Operations start in state OPSTAT “Waiting” until it is no longer dependent on any prior
operation or command and can be executed. It then goes to “Ready” and put into a list
ready for execution. Execution takes place in a separate thread and the state is then
“Running”.
During the running state Failures and Successes may be generated as well as messages.
But these are not stored in the database immediately.
When the operation finishes (TRPASS set to true or false) the OPSTAT is set to “Complete”
and successes and failures stored in the database under the TROPER (and not before this).
The finishing may also set a string in MSTEXT, but this is not passed on.
The execution of an operation can stall due to inability to access data for example. In this
case the OPSTAT is set to “Stalled” and will be reset back to Ready after time WAITIM. The
number of retries after stalling is stored in NRETRY. Operations will time out if still stalled at
date ENDTIM or the number of retries exceeds MAXTRY. In this case OPSTAT goes to
“Complete” and finally “TimedOut”.
When an operation is complete it may need to generate extra operations and commands the
form of which are dependent on the results of the operation. If this create operation is stalled
then the operation goes to OPSTAT “Stalled Post Operation” and will go back to “Complete”
after WAITIM. When post operations are successfully created, or none are needed, then the
operation goes to a final state that is “Processed” or “Timed Out”.
TROPERs may never be needed if dependencies are not met in which case they terminate
in state “Redundant”. This may happen if a command is cancelled.

7.4 Audit Trail Dates and Counts

States of input and output commands and operations are often progressed a number of
times and for some, though not all states, a count attribute is incremented. This gives
information about the number of times commands are sent, or tried or stalled for example.
A number of states also have an associated date attribute which is set each time the state is
reached so that it records, for example, the date when a command was last sent, or
acknowledge.
The states that set associated dates and counts are:
TRINCO:
RECEIVED DATECR Date command received from user or other

location and created
ACKNOWLEDGED DATEAK Date acknowledgement for command sent
NACKN Number of times acknowledgement sent
READY DATERD Date command made ready (after EXTIME
has been reached)
COMPLETE DATECM Date command completed
REPLIED DATERP Date reply sent with results of command
NREPLY Number of times reply sent
TIMEDOUT DATEND Date command timed out. No ops created
CANCELLED DATEND Date command cancelled by user
PROCESSED DATEND Date all processing of command finished
including reply acknowledgement of
command received
NREPAK Number of times reply acknowledgement
received

TROUCO:
WAIT DATECR Date command created by owning TRINCO

or previous TROPER or TROUCO
READY DATERD Date command made ready to be sent when
dependencies satisfied
SENT DATESN Date command sent to target location
NRETRY Number of times command sent and stalled
ACKNOWLEDGED DATEAK Date command acknowledgement received
NACKN Number of times acknowledgement received
REPLIED DATERP Date reply received with results of command
NREPLY Number of times reply received
COMPLETE DATERK Date command completed and reply
acknowledgement sent
NREPAK Number of reply acknowledgments sent
TIMEDOUT DATEND Date command timed out. Could not be sent
CANCELLED DATEND Date command cancelled by owning TRINCO
REDUNDANT DATEND Date command discovered to be redundant
PROCESSED DATEND Date all processing of command finished -
including post operations generated.
TROPER:
WAIT DATECR Date operation created by owning TRINCO or

previous TROPER or TROUCO
READY DATERD Date operation set ready when all dependencies
satisfied,
RUNNING DATERN Date operation started running
NRETRY Number of times operation was set running
STALLED DATESL Date operation stalled
COMPLETE DATECM Date operation completed
TIMEDOUT DATEND Date operation timed out. Could not be run
CANCELLED DATEND Date operation cancelled by owning TRINCO
REDUNDANT DATEND Date operation discovered to be redundant
PROCESSED DATEND Date all processing of operation finished - including
post operations generated.

7.5 Cancelled Commands

Commands can be cancelled at the location where they were first input. There are rules as
to what a particular user may cancel, but this section describes what happens in the
daemon once a cancel command has been passed to it.
Cancellation only applies to TRINCOs and not to any particular operation it has. The
cancellation is immediately effected if the TRINCO has INCSTA of state “Waiting” or
“Stalled”.
If the TRINCO is “Ready” then all of its operations and output commands are inspected. If
these TROPERs and TROUCOs are all “Waiting”, “Ready” or “Stalled” then those in “Ready”
or “Stalled” state are set to “cancelled” and the waiting ones become “Redundant”. And the
TRINCO becomes “Complete” and then “Cancelled”.
TRINCOs in other, later states are not cancellable and the cancellation is rejected.
A Message is stored with the command as to whether the cancellation was effected, or
rejected.
7.6 Processing of Results and Messages

When operations execute they may generate successes and failures. These are buffered
and written to the transaction database as TRSUCC and TRFAIL elements when the
operations becomes “Complete”. Specific messages may also be generated. Messages are
automatically generated for each success and failure, each time an operation or output
command stalls.
Input Commands can have messages. These are automatically generated if the create
operations stage stall and if a cancel is attempted. There may also be failures and
successes but these are rarely generated.
Messages are not stored in the database except under the TRINCO that was originally
received from a user (not another locations TROUCO) and under the TROPERs and
TROUCOs that the TRINCO owns. This is because messages are collected together
regularly by each TRINCO as its operations progress and these are passed back to the
TRINCO’s originating TROUCO. If the sender was the user then the messages are stored in
the database for review under the relevant element: In particular when these messages are
passed between sites the TROUCO receives a set of messages each of which may have
been generated by different operations, and yet they will now all belong to the single
TROUCO. The messages contain sufficient attribute information to indicate the location that
the message originated from, the operation type etc.
When the messages are finally stored below the originating command successes and
failures are persisted as TRSUCC and TRFAIL elements under a TRMLST element. This
will distinguish them from the result successes and fails that are persisted when the
operation or output command finally completes.
The diagram on page describes the elements created for a simple command claim,
between 2 locations. It provides an idea of the elements created in both transaction DBs.
7.7 Transaction Success and Failure Messages

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

7.7.1 Scheduled Updates - Successes

A successful scheduled update normally reports two messages:
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 that 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 that this will always report a success even if
there is nothing to transfer or ‘Other data transfer’ is not set up.
7.7.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

55 Scheduled update was suppressed Attribute LNOUPD set TRUE on
LCOMD to disable scheduled
update
67 Remote location CAM is unavailable Daemon for CAM is not available;
56 Update will not report results to CAM this failure cannot be reported at
CAM - usually due to location
unavailable
612 Prevented reverse copying Secondary location has a higher
compaction number than the
primary location. Database may
need recovering
611 Prevented reverse update Secondary location has a higher
session number than the primary
location. Database may need
recovering
613 Unable to check update direction - The Global database is in use. This
update skipped is normally temporary, due to
another command.
610 Update skipped - cannot get local The specified database is in use at
details for <database> the 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
details for <database> the remote location. This is normally
temporary.
610 Update skipped - cannot get local/ In the case of system databases, if
remote details for CAM system DB one system db is in use, then the
update will fail for any system db
(they all have the same DB number)
616 Failed database copy - file may be in Unspecified COPY failure -
use at HUB compaction 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 -
failed COPY compaction numbers are still out of
step. No further detail is available.
617 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.
628 Failed database copy. File in use. Database file is locked and
Cannot remove overwriting 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.7.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. Note that the ‘Successful file copy’ success reports that nothing has been copied,
since the remote copy stage was executed successfully on an earlier try, when the copy
failed.
Detailed failures for file copies can only be reported at the destination. During a scheduled
update, the success of a copy is verified by checking that the compaction number has
changed. If the copy was executed at the location which executes the scheduled update,
then additional failures may show more detail. (Note this is the partner location for a
scheduled update, not the originator!)
7.8 Reasons Other ADMIN Commands Can Fail

Many daemon commands used for project administration include operations that change
the Global database. These operations fail if they cannot claim the appropriate element,
typically because ADMIN still has the element claimed.
Action Cause of Failure

Commit Allocate DB Changes DBALL members, owned by LOC
Commit Allocate All Changes DBALL members, owned by LOC
Commit Allocate Primary DB Changes DBALL members, owned by LOC
Initialise Changes LOC element
Set Systemloc Changes LOC element
Set Primary Changes DBLOC element, owned by DB
Remove all DBs from MDBs Changes MDB elements at satellite
Remove from MDB Changes MDB elements at satellite
Delete from MDB Changes MDB elements at satellite
Change Hub Changes GLOCWL /*GL
Recover Hub Changes GLOCWL /*GL
Unlock DB allocation Changes DBLOC element, owned by DB
Unlock All db allocation Changes DBALL element, owned by LOC

Refer to Extract Flush Commands Failing and Reasons Claims and Flushes can Fail for non
Admin command failures.
7.9 Automatic Merging and Purging of a Transaction

Database
Facilities are available for automatically merging and purging each transaction database, in
order to reduce its size and, consequently, improve its efficiency.
The principle of operation is that the system administrator can set rules that determine how
long successful commands and/or failed commands can remain in the transaction
database. At regular intervals, set by the administrator, the system deletes the expired
commands, merges the database to a new file, deletes the existing file and then copies the
merged file to the original filename.
As with all databases, the merging of a transaction database can be carried out only when
no other users are currently accessing it.
The procedure for initiating automatic merging and purging and setting the rules is in the
Global User Guide.
The Global User Guide also contains information on manually merging and purging
databases.


Pending File
8 Pending File
On a Global network, most remote commands that are stalled for any reason at a location
are placed in the transaction database at that location, for later processing, (see next
chapter).
A small number of commands that cannot be carried out at once, known as ‘kernel’
commands, are instead stored in a location’s pending file for later processing. There are
various situations where kernel commands may be added to a pending file. For example:
• Too many commands have been issued in quick succession.
• A communication link is down.
The kernel commands are:
• ISOLATION TRUE/FALSE
• LOCK/UNLOCK
• PREVOWNER HUB
Also, for a Satellite’s transaction database:
• ALLOCATE (PRIMARY)
• CHANGE PRIMARY
All other commands use the transaction database to achieve a similar effect (see next
chapter).
Once a pending file has been created at a location, it will continue to exist. When the kernel
commands stored in it have been executed, they will be deleted from the file. The user can
tell if there are any outstanding commands by the size of the file: if it is empty, it will be zero
size. The contents of the pending file can be read by using a utility available from AVEVA.
The pending file is named pending, and it will be saved in the project directory (for example,
abc000). It can be read using the glbpend.exe utility provided in the Global install folder.
For example, if the pending file is C:\AVEVA\projects\abc000\pending, the command to read
it is:
install path\glbpend.exe C:\AVEVA\projects\abc000\pending
The pending commands can be read from the output.

Pending File

Changing the Hub
9 Changing the Hub
9.1 Preparation for Changing the Hub

Changing the Hub is a straightforward process, but any break in communication links could
potentially complicate matters. Global can handle and recover from communication failure,
but AVEVA recommend the following preliminary steps are taken to minimise the risk of Hub
change failure:
• Make sure that the daemon is running at both the current Hub and the Satellite which
will become the new hub. This can be done by selecting Query > Global States >
Communications from the ADMIN, DRAW, MODEL or SPOOL module or by issuing a
Ping command.
• Make sure that the project at the Hub is backed up and that at least the Global
database (i.e. prjglb) at the satellites is backed up.
Once these steps have been taken, the user can change the Hub through the
command line. The GUI will automatically change at the old Hub. At the new Hub, re-
enter ADMIN.
Output to the Global daemon window will indicate that the location is now the Hub or
Satellite.
• Note that all databases, including non-propagating databases must be allocated to the
proposed new Hub, for example /Tokyo, before changing the Hub. This may be done
using the command:
Allocate all at /Tokyo override propg
• or by checking the option ‘Allocate all’ to allocate non-propagating databases on the
Database Allocation (by location) form.
Make sure that the change of Hub location is complete before working with either the new or
old Hub. Check the following attribute to confirm that the hub change has been successful.
For example, if the user is changing the Hub from London to Tokyo, then navigate to the
location world /*GL and query the Hubrf attribute:
/*GL
q hubrf
The Hubrf should be set to the name of the new Hub location; in this example, /Tokyo.
See that the location parent attribute of each location (locrf) has changed. This is a
secondary effect, because the Hub location can have no parent. In the above example,
navigate to the location of the old Hub and query the Locrf attribute:
/London
q locrf
The Locrf should be set to the name of the new Hub location; in this example, /Tokyo.
(Previously, London, as the old Hub, had no parent location.)

Changing the Hub
Now, navigate to the location of the new Hub and query its Locrf; for example:
/Tokyo
q locrf
If the Locrf of Tokyo is set to Nulref, then the hub change has been successful. The new
hub, Tokyo, has no parent location.
9.2 Recovering from Change Hub Failure

Very rarely, the project may be in a state where a Hub change has been carried out but has
failed. In this situation, the user may effectively have no Hub.
During a Hub change, or when a Hub change has failed, the identities of the old and new
hubs are recorded on the Location World /*GL. Navigate to the location world and query
Hubrf, Prvrf and Nxthb attributes:
/*GL
q hubrf
q prvrf
q nxthb
When there is no Hub, then Prvrf records the name of the previous hub and Nxthb records
the name of the next hub. The Hubrf attribute is set to Nulref. During a Hub change from
London to Tokyo, Prvrf would be /London and Nxthb would be /Tokyo.
Normally, when a Hub change fails, the previous Hub will be restored automatically as part
of the failure operations of the Hub change. The user should check progress of the
command in the transaction database. If this recovery fails, then the System Administrator
must recover the previous Hub as described below. This will be necessary in the following
circumstances:
• If the daemon is down
• For offline locations
In all other circumstances it is better await the completion of the in-built recovery
operation, since this prevents incompatible changes being made by two competing
users at different locations.
To force recovery from a failed Hub change, at the original Hub, use the
Data>Recover>Hub Location option from the ADMIN menu bar, or type the following
command:
PREVOWNER HUB
Re-enter the ADMIN module. This will restore the Hub location and the Hub GUI. (Note: if
daemons are running, then the original Hub location command may still be in progress and
will attempt to commit the hub change or recover the original hub as appropriate)
Make sure that the PREVOWNER command is complete before working with either the new
or old Hub, as otherwise it is possible to end up with two Hubs. If this happens, the Global
database must be propagated (or physically copied) from the new Hub to the old before
further administration is be carried out. If the new Hub was to merge changes while the old
Hub was still active, the system would not be able to recover. It would be necessary to
reinstate the Global database from the backup taken before the change of Hub location was
undertaken.

Updates and Synchronisation
10 Updates and Synchronisation
Within Global there is the functionality to update databases automatically or manually.

Additionally, we can manually synchronise databases.
10.1 Synchronisation
Synchronisation can be carried out at both Hub and Satellite locations. This process can be
used to synchronise databases at one location with the corresponding databases at a
different location. This is a one-way process: project data is only received.
10.2 Manual Updates

Manual updates can also be carried out at both Hub and Satellite locations. This is a two-
way process that can take place between neighbouring Locations. Data will be both sent
and received from the location initiating the update, according to which Location has the
most up-to-date version of the database.
If update is used between two locations which are not neighbours, then Global will attempt
to synchronise the database at the two locations as follows:
• If the sending location is the primary location, it will update the database at each
location along the network path to the destination;
• If the receiving location is the primary location, it will execute a SYNCHRONISE
command to request an update from the primary location
• If the primary location lies between the two locations, then it will synchronise the
database at the sending location with the primary location and update the database
from the primary location to the destination location.
It is also possible to do a direct update between two non-neighbour locations using the
UPDATE DIRECT command. However this is not recommended, since it can result in
‘Reverse propagation’ errors from scheduled updates. This happens because UPDATE
DIRECT results in the database being more recent at the secondary destination of the
update than at the intermediate satellite through which scheduled updates are routed.

To learn more about Reverse Propagation errors, see Recovery from Reverse Propagation
Errors.
10.3 Update and Timing Considerations

Remember that changes to automatic updates may take up to 15 minutes to take effect.
This is because the daemon checks the pending file every 2.5 minutes. This happens six
times before the System databases and the update information are re-read. Thus, we have
the possibility of a maximum delay of 15 minutes before updates are started. If necessary,
this delay can be reduced by stopping and re-starting the daemon.
10.3.1 Propagation of Databases of Access-Type Update

When Global propagates a database with access Update, it locks out the users from that
database. This will affect the users during Save Work, Get Work and Module-switching,
who may experience this as base product 'hanging'.
It is recommended that:
1. Only databases with access Multiwrite should be used in the Global project.
2. Otherwise Global Update Events should be scheduled outside normal working hours
(this is not always possible in world-wide projects, but can be achieved by using an
intermediate satellite for transfer across time-zones).
3. Access Update can be used with non-propagating databases, since these are not
transferred by Global.
4. Access Update is also acceptable where a database is modified rarely, for example a
dictionary (DICT) databases.
10.4 Propagation of Picture and Neutral Format Files

Picture and Neutral Format files are propagated the same time that a Database is
propagated. If the Daemon finds that a Database has been modified at its primary location it
will query the Picture directory (referenced by variable %ABCPIC% in the case of a PADD
database), and the Neutral Format directory (referenced by variable %ABCDIA% in the

case of a SCHE database) at both locations to work out any changes. New and missing files
will be copied from the Primary Location to all Secondary Locations.
Note: The picture file will not be deleted if it is also used by another extract of the database.
The picture-file will ONLY be deleted if it is owned by the same extract as the current extract.
This may result in picture-files which have been created by other extracts in being retained.
This is to avoid the situation where a picture-file which is still in use in another extract is
deleted. The command PURGE DB <dbname> may be used to purge unused picture-files.
If the Database is found to be the same at both locations, then it is considered not to require
Propagation, and the Picture and Neutral Format File directories are not compared.
Therefore if there is a genuine mis-match in the file directories this will not be resolved.
By Default Picture and Neutral Format File Propagation is Disabled (non-propagating), it is
possible to enable the Propagation of these files by ticking the check box on the Modify/
Create dB window, as below. This will allow Picture and Neutral Format files to be
propagated to any other location.

If this is done it is possible to regenerate all Picture and Neutral Format Files at the satellite,
even though the Database is secondary.
For Picture and Neutral Format Files to be successfully propagated the environment
variables %ABCPIC% and %ABCDIA% must be set in the Daemon kick-off script.
Note: Global limits the number of picture files that can be propagated per database.
Because of this, the user should not create more than 500 pictures or Neutral Format
Diagrams per DRAW database. This generally means limiting the number of SHEE
and OVER elements; if necessary, create extra DRAW databases to allow more
pictures to be created.
Marine Drawings files are always propagated, even if Picture/Neutral Format File
Propagation is disabled.
For Marine there are drawings in the ASSI, ASSP, BACK, BTEM, CPAR, MARK, NPLD,
NSKE, PDB, PICT, PINJ, PLIS, PLJI, PPAR, PRSK, RECE, SETT, STD and WCOG
directories.
10.5 Propagation of Marine Drawing Files

Marine Drawing files differ from Picture and Neutral Format Files because they are always
propagated regardless as to whether the Propagate Picture/Neutral Format Files check box
is unchecked or not. The reason for this is that, unlike picture files, Marine files cannot be
regenerated at a secondary location.
For these files to be successfully propagated the following environment variable must be set
in the Daemon kick-off script:
Marine Hull Drawing {ABC} DRG
Diagram {ABC} DIA
Stencil {ABC} STE
Template {ABC} TPL
SVG (Neutral Format) {ABC} DIA
10.6 Propagation of Inter-Database Macros

As in a non-Global projects, inter-DB macros will be created, for example, when a user tries
to connect a pipe in one database to a nozzle in another database for which that user only
has Read access.
Within a Global environment, inter-db macros may need propagating to various locations. In
order for this to be successful, carry out the following:
• The macro directory, (for example,. abcmac), must exist at all locations where macros
will be created.
• The project variables for the macro directory (for example, ABCMAC) are set for the
daemons. (All project environment variables must also be set for users, of course.)

10.7 Propagation of Linked Documents

The user may specify that certain external files are linked to the Design using a Link
Description element (LNDESC). If the URL is a file URL of the format 'file:///myfile' and the
Link Propagation attribute LNKPRP is set to SEND, then Linked files can be propagated.
The file URL must reference a file location which exists at both the primary and secondary
locations of a database. It is thus useful to specify file-paths in terms of environment
variables, e.g. 'file:///%AAAINFO%\myfile'.
Note: Global does not create folders, these must already exist at the secondary location.
Linked document propagation is disabled by default for the project. To enable Link
propagation, the GLINKP attribute of the element GLOCWL /*GL must be set to TRUE:
Once enabled for the project, Link propagation is enabled for all Design databases, whether
or not they actually contain Linked documents. Additional operations are invoked to
propagate Linked documents. It may therefore be useful to disable Link propagation for
those Design databases which will never contain links. There is a check box on the Create
Database window for this:

Important: Linked documents will only be transferred when a database update has
transferred data. By default only missing documents will be copied and by
default documents will not be replaced if they already exist.
Propagated Link documents are not deleted at secondary locations even if they
are at the primary location.
SYNCHR/ONISE <dbname> LINKDOC/UMENTS

This command checks whether any Linked documents need transferring for a specified
Design database. It is possible to overwrite existing Linked documents at the secondary
location using the keyword FORCE:
SYNCHRONISE <dbname> LINKDOC/UMENTS FORCE
When a database is ALLOCATEd or RECOVERed, then any existing Linked documents will
be replaced.
10.8 Update Timings

It is extremely difficult to predict the length of time that an update will take to complete. It will
depend upon the bandwidth that is dedicated to the update process at the time it is run.
Therefore, if the line is shared with other comms programs (mail, internet, etc), the update
performance will be affected. The timings described below were undertaken on a line that
had no other process competing, and a line that was extremely clean - that is, its rate of
failure would be near zero. On a normal WAN line, its collision and failure rate would not
achieve anywhere near such a low level.
Line Speed Time Rate of Transfer Rate of Transfer

(bits per sec) (H.M:S) (bytes per sec) (Kbytes per hour)
38,400 1.41:18 3,734 13,128
64,000 0.57:15 6,607 23,229
125,000 0.30:17 12,491 43,913
250,000 0.16:24 23,065 81,088
500,000 0.09:06 41,568 146,136
1,000,000 0.06:07 61,842 217,413
2,000,000 0.04:04 93,016 327,010
4,000,000 0.02:26 155,452 546,510
These test timings were taken when propagating 11080 pages (22695936 bytes) of data
between two machines.
10.9 Transfer of Other Data

Files such as ISODRAFT files, external PLOT files and MODEL manager 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. These files
are transferred by scheduled updates and the UPDATE ALL command.
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
myfile is to be sent on to other locations, it will need to be copied into the export directories
at BBB for those locations.
Offline locations: The TRANSFER command only copies databases and picture files to or
from the transfer directory, ready for onward manual transfer to the specified location.
Transfer of other data files must be done manually.
It is possible to assign a batch script to run both before and after the Update Event occurs.
This can be used to copy data into the EXPORT directories before the Update is executed,
and then copy it out of the IMPORT directory once the Update Event has completed. This
process will include the transfer of Other Data.
The batch scripts are assigned to an Update Event through the Create/Modify Update
window, see below.
Batch Scripts
The script itself can be of any type of batch script, for instance perl, and can be as complex
as required.

10.10 Reverse Propagation Prevention

When a database update is initiated, a check is automatically made to make sure that the
update direction is correct. If the check implies that the propagation is in the reverse
direction (that is from out-of-date database to up-to-date database) the update is aborted
and an error message 'Prevented reverse update' or 'Prevented reverse copying' is
displayed. Note that this check cannot be made if the primary location is being changed.
The check involves an analysis of the status of the two databases. The result of the analysis
determines the appropriate propagation direction. This propagation direction is compared
with that expected at the primary location and the update is allowed to continue only when
these propagation directions are the same.
The database status that is analysed comprises a Non-additive Changes Count (NACCNT),
Header Changes Count (HCCNT), Claim List Changes Count (CLCCNT) and the Latest
Session. The three counts are pseudo-attributes of the DB element, and can be queried.
The message 'Prevented reverse update' means that the session data or the header page
at the secondary location is greater than at the primary location. This may be investigated
by checking the session number at each location, and, if necessary, by querying the HCCNT
attribute at the DB elements of the databases.
The message 'Prevented reverse copying' means that the NACCNT at the secondary
location is greater than at the primary location. This attribute may be queried at the DB
element of the database at each location.
It may be necessary to recover the database at the secondary location to solve the problem.
If either of the above messages is reported for a system or Global database, a similar
investigation can be made. For a system database the HCCNT and NACCNT attributes
should be queried at the STAT /*S element. For a Global database, they should be queried
at the GSTAT /*GS element.
To resolve the problem, the database at the appropriate location must be recovered.
Refer to Recovery from Reverse Propagation Errors for further information.


Deleting Databases
11 Deleting Databases
The procedure for deleting a database is summarised below. If the database owns extracts,
see Deleting a Database that owns Extracts.
Note: A dB does not need to be primary at the HUB, just as long as it is not primary at the
location where it is being deallocated.

Deleting Databases

Database Recovery
12 Database Recovery
If for any reason a database at a location is corrupt, it can be recovered by transferring the
database from a neighbouring location. It is important to remember that this could result in
loss of work. The main objective when a recovery is carried out is obviously to restore the
database(s) and minimise the work loss.
Global does not verify that the file from which the database is being recovered is a valid
database. It is the user's responsibility to make sure that this is the case. Remote DICE
checking may be used to verify the state of the database at the remote location from which
the database is to be recovered.
12.1 Recovering Secondary Databases

The user would recover a secondary database from a neighbouring location that has the
most up-to-date database. This will usually be from the Primary Database. For example, in
the diagram below, 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

Database Recovery
Location of Corrupt DB Corrupt DB Recover Corrupt DB From

12.2 Recovering Primary Databases

Recovering primary databases requires a little more consideration. 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.
The main aim here is to recover the database from the most recent backup or from a
secondary location with minimal work loss.
• 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 this database is an uncorrupted and newer
database than the one in the backup. (The user should restore from the latest
secondary database.)
Some corruption can be fixed by DICE, so try using DICE first if recovering to a primary
location.
This method can also be used to recover the system database. However, the system
database cannot be recovered by the daemon unless it is readable, since the daemon
uses it to understand the network. If the system database cannot be read, then it must
be restored manually.
Note: When a DICE report indicates that Refblocks have been lost, normally this would
require the master database to be patched. However in a Global project, this error is
non-fatal if there are working extracts. These databases are non-propagating and
only exist at the primary location of their extract owner. This results in the error
report, since the Refblocks for working extracts are not accessible at the primary
location of the master db. (Refblocks are blocks of reference numbers available for
use in the extract).
12.3 Recovering Database Primary Locations

If changing the Primary location of a database fails for some reason, use the PREVOWNER
command to recover the Primary location.
12.4 Recovering the Global Database

If for any reason the Global database at a Satellite becomes out of date, first try fixing the
problem by using DICE, the base product Data Integrity Checker. If the user cannot fix the
problem using DICE, the database at a Satellite can be recovered by the following
procedure:
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 (for example abcglb) from the hub to the satellite.
4. Restart the daemons and allow users to start work again.

Database Recovery
12.5 Transaction Database Management

The transaction database records details of Global daemon commands at a location. Each
location has its own transaction database.
The transaction database is unusual in that the base product treats it both as a system
database and as an ordinary user database. By default, it is a non-propagating database,
thus secondary databases at other locations are likely to be very out of date with the primary
version at the owning location.
Note: To avoid data consistency errors, changes to the transaction database should not be
made while the daemon is running
12.5.1 Renewing the Transaction Database

If the transaction database becomes corrupt, it may be necessary to delete and re-create it.
At the Hub, this may be done using the ADMIN Module. However, at satellites it is not
possible to delete and create databases directly.
Instead, the satellite transaction database must be renewed using the daemon. This may be
done in one of the following ways:
• The RENEW DELETE <DB> command may be used. This is the preferred method of
re-creating the transaction database file, as it works even when the database is too
corrupt for the daemon to run. Note that <DB> must be the transaction database for the
current location, as the command cannot be executed remotely.
Following the command, ADMIN checks that all users are logged out and that the
daemon has been shut down. Note that the check on the daemon takes up to 3
minutes. ADMIN then deletes the file for the transaction database (not its DB entry) and
prompts the user to quit and to stop and re-start the daemon. When the daemon is
restarted, it will automatically recreate the transaction database file.
• The RENEW <DB> AT <loc> command may be used to renew a transaction database
remotely. Note that this command may fail, if the database corruption is severe and the
daemon at <loc> cannot be started.
• If the transaction database file for a location is missing, the daemon will create a fresh
version automatically when it is started up. This means that if for some reason the
database is corrupt, the transaction database can still be renewed by deleting the
corrupt version of the file manually. (Do not delete its definition in the Global database)
After renewing, copy the location’s transaction database to all secondary locations
(such as the Hub), using the RECOVER command. This will prevent reverse
propagation when the database is synchronised at a secondary location.
Note: The RENEW command may remove running commands because it deletes the
transaction database.
12.5.2 Merging the Transaction Database

The transaction database may be merged from the ADMIN Module. This requires the
daemon to have been closed down at that location, so that there are no write-access users
of the location's transaction database.
It may also be merged remotely at the daemon, using the REMOTE MERGE command. The
Global daemon detects that the database involved is the location's own transaction
database. The daemon will close the transaction database before the merge, and re-open it
afterwards.

Database Recovery
However, the REMOTE MERGE command cannot be used when the transaction database
is full, since this command cannot be recorded properly. In this case, it may be necessary to
merge it by reconfiguring. To manage the transaction dB efficiently TRINCOs (and their child
elements) need to be deleted at regular intervals. Only completed transactions should be
deleted. It only makes sense to merge the transaction dB after TRINCOs have been
deleted, otherwise the dB will not be compacted.
12.5.3 Reconfiguring the Transaction Database at a Satellite

It is possible to recover a corrupt transaction database at a satellite by reconfiguring it. This
is more complicated than reconfiguring it at the Hub, because the TO NEW command
cannot be used at a satellite.
The procedure is as follows:
1. In the ADMIN Module at the satellite, reconfigure FROM the corrupt transaction
database TO files.
2. Renew the transaction database by one of the methods described in Renewing the
Transaction Database.
3. Stop the daemon at the satellite (if this has not already been done).
4. In the ADMIN Module at the satellite, reconfigure FROM the files created above TO the
transaction database.
After reconfiguring, copy the location’s transaction database to all secondary locations
(such as the Hub), using the RECOVER command. This will prevent reverse
propagation when the database is synchronised at a secondary location.
It is essential when reconfiguring the transaction dB that the SAMEREF option be used.
Transaction dBs from other locations have references direct into a local transaction dB, and
failure to do so will result in the references changing.

Recommendations for Reconfiguring (User dBs)
13 Recommendations for Reconfiguring (User

dBs)
It is recommended that, when reconfiguring databases, the SAMEREF option be used.

Using this option makes sure that referencing databases are unaffected.
Take care when reconfiguring project databases. Databases can only be reconfigured at
their primary locations. It is important to note that when a project database is reconfigured,
the database sessions will effectively be lost. Thus the ability for Global to send only session
changes is lost as well.
It is therefore recommended that the REMOTE MERGE command is used to synchronise
and merge the database at all secondary locations (unless the database is non-
propagating). This prevents propagation of the entire database on the next update.
It is also recommended that there are no users in the database at the primary location when
reconfiguring back to the Sameref database.

Recommendations for Reconfiguring (User dBs)

Copying Global Projects
14 Copying Global Projects
Global projects may be copied. Facilities are provided to:

• replicate the complete Global project, including all data (except the ISO
subdirectories), to a new project
• replicate the structure of a Global project to file
• This is achieved using the REPLICATE command.
• For full details of the REPLICATE command, see the Administrator Command
Reference Manual.
Note: It is very important to make sure that the replicated project has a different project
UUID to the original project, otherwise the Daemon will not run correctly.
The UUID for the project is stored in the ADUUID attribute of /*GL.
If this is unset or has not been changed use the NEWUID attribute:
/*GL
!NEW=NEWUID
ADUUID ‘$!NEW’
SAVEWORK

Copying Global Projects

Backing Up Global Projects
15 Backing Up Global Projects
Backing up projects regularly is good practice in any environment, including Global projects.
With a Global project, extra attention has to be given to any restoring process that is carried
out. The following guidelines are outlined in relation to backing up Global projects:
• Backup all files at all location regularly.
• When restoring a project, be aware that the user may be able to restore project
databases by using Global’s Recover functionality. This may give the opportunity to
minimise work loss.
• Use the backups for a location only for that location. (In some cases the only option
may be to use backups from other locations. In this case, be aware of the implication it
could have on the amount of work lost.)
Remember, Global database (for example abcglb) at the Hub is the ‘master’ Global
database. Back this up before carrying out any major Global administration work.
When using databases from backups, it is feasible for a secondary database to have newer
sessions than a primary database. If so, at the next update, changes may be posted back
from the secondary database to the primary database. If new sessions have been written at
the primary location, this could cause corruption. Therefore make sure that their secondary
database backups do not have newer sessions than the primary database.
To resolve this, it may be necessary to RECOVER some databases from the primary
location after the restore.

Backing Up Global Projects

Using Extracts with Global Projects
16 Using Extracts with Global Projects
An extract is created from an existing database. When an Extract is created, it will be empty,
with pointers back to the owning or master database. Thus all data visible in the master will
be visible in the extract. Extracts can only be created from Multiwrite databases, and all
extracts are themselves Multiwrite. The user can create Extract DBs from any type of
database that can be multiwrite, that is DESI, PADD, CATA and ISOD, and in the case of
Marine projects, MANU and SCHE.
• Extracts from foreign DBs cannot be created.
• Extracts from copy DBs cannot be created.
The user can work on an extract at the same time as another user is working on the master
or another extract. When a user works on the extract, elements are claimed to the extract in
a similar way to simple multiwrite databases, so no other User can work on them. When an
extract User does a SAVEWORK, the changed data will be saved to the Extract. The
unchanged data will still be read via pointers back to the master DB. When appropriate, the
changes made to the extract are written back to the master. Also, the extract can be
updated when required with changes made to the master.
16.1 Using Extracts

The user can use extract databases both with standard (non-Global) projects and with
Global projects. This chapter gives information about the use of extracts with Global
projects. Refer to the Administrator User Guide for information about the use of extracts with
standard projects.
16.1.1 Extract Families

A Master DB may have many extract DBs. The user can create an extract from another
extract, forming a hierarchy of extracts. The hierarchy can be up to 10 levels deep. The
extracts derived from the same master are defined as an Extract Family. The maximum
number of extracts at all levels in an extract family is 8191.
The original database is known as the Master database. The Master database is the parent
of the first level of extracts. If a more complex hierarchy of extracts is created, the lower
level extracts will have parent extracts which are not the master.
The extracts immediately below an extract are known as extract children. The maximum
number of extract children is 408.
If a hierarchy of extracts is created, the parent of an extract, and its parents up to and
including the Master DB, are known collectively as the Extract Ancestors.
The following diagram illustrates an example of an extract family hierarchy:

In this example:
Label Description
PIPES is the Master and the parent of PIPES_X1.
PIPES_X1 is a child of PIPES and the parent of PIPES_X10.
PIPES_X10 is a child of PIPES_X1.
Note: The children of PIPES are PIPES_X1 and PIPES-X2. PIPES and PIPES_X1 are the
ancestors of PIPES_X10.
Write access to extracts is controlled in the same way as any other database:
• The user must be a member of the Team owning the Extract. Extracts in the same
family can be owned by the same team or by different teams.
• The user must select an MDB containing the extract (or containing its parent, if the
extract is a working extract).
• Data Access Control can be applied.
• An extract database cannot be opened in a constructor module (such as MODEL) at a
satellite unless all its parent extracts are also allocated to that satellite.
Note: At this release, you can only create an extract at the bottom of an extract tree: you
cannot insert a new extract between existing generations. At the Hub, you can also
create a new master database above the original master.
16.1.2 Querying Extract Families

The user can query the following attributes to get information about the structure of an
extract family, at a database element in the Global database.
EXTNO Extract Number
EXTOWN Extract Owner
EXTMAS Extract Master
EXTALS Extract Ancestors
EXTCLS Extract Children

EXTDES Extract Descendants
EXTFAM Extract Family
ISEXOP Is Owner Primary Here?
ISEXMP Is Parent Primary Here?
ISEXAP Is All Ancestry Primary Here?
LVAR Variant
LCTROL Controlled
16.2 Creating Master and Extract Databases
16.2.1 Creating Master Databases

All master databases (that is, normal multiwrite databases which are going to have extracts
created from them) must be created at the Hub. They can be created before giving the
make global command.
Specify the database numbers for each database. For example:
cr db pipe/pipe-a desi acc multiwrite dbno n fino n
(If fino is specified, then this will be used to define the filename, otherwise the database will
be named using its dbno and extract number - default 1).
16.2.2 Creating Extracts

Extracts can be created at any authorised Location: the parent extract must be allocated to
the Location first.
Like other databases in a Global project, extracts have a primary Location, and this need not
be the same as the Primary location of the parent database. By default, the primary location
of the new extract will be the current location.
• If the user is at the Hub and creating an extract for a satellite, use the AT option in the
CREATE command. The extract will be created with its primary location at the Satellite
specified.
• If the user is at an administering location, the user must also use the AT option to
specify that the extract will be created at the administered location, otherwise the
extract will be created at the administering location (that is, the true current location,
queried using Q CURLOC). The parent extract must be allocated to the administered
location.
• When creating an Extract at a satellite, make sure the CREATE EXTRACT command
is given only once and check that the command has completed by issuing a Q DB
dbname command. The user can issue further CREATE EXTRACT commands
provided that the user does not use the same db name or db number (if specified). The
daemon will assign a db number (dbno) if none is specified.
The CREATE EXTRACT command will be executed by the Daemon (which will imply a
delay in executing the command) if any of the following is true:
• If the master database is primary somewhere else

• If the current location is a satellite

• If the parent extract is primary at another location
• If the new child extract is specified to be primary at another location (AT loc option).
Note: An in-built recovery operation exists for CREATE EXTRACT and, therefore, the
PREVOWNER command is not usually needed after a failure of the CREATE
EXTRACT command. However, the automatic recovery operation does not cover the
CREATE command Allocate operation and PREVOWNER may be needed in the
unlikely event of this failing.
Note that the ALLOCATE Command allows child extracts to be allocated to a satellite
without their parent being allocated, but the user will not be able to open the extract until all
its ancestors have been allocated to the location. Also note that the ancestor extracts may
need to be synchronised, if timed updates of extracts has not been implemented.
Extract creation is controlled by the NOEXTC attribute of a location. If this is TRUE, then
extract creation is disabled and extracts cannot be created by that location. However the
Hub or its administering location (if authorised) may create extracts.
The purpose of the NOEXTC attribute is to prevent a satellite from creating databases on
the fly without authorisation, and it applies to the administering location, not the
administered location. However, if the HUB is doing it, it is by definition authorised. Thus the
HUB is always able to create extracts.
Similarly, we could have a situation where one satellite AAA is administering another BBB.
Satellite AAA might have NOEXTC false, and BBB might have NOEXTC true. In this case,
AAA would be allowed to create extracts for itself and for satellite BBB.
But BBB would not be allowed to create any extracts itself. The screenshots below show
how to set the NOEXTC attribute in the Modify Location window.

16.2.3 Creating Working Extracts

Working extracts can only be created at the location where the parent extract is primary.
Working extracts do not need to be added to MDBs. When selecting an MDB that includes
databases for which you have working extracts, it will actually write your data to the working
extract.
When issuing data from a working extract, it will be issued to the database from which the
working extract has been created.
In order to issue data from an extract which has working extracts to an extract further up the
extract tree, there must be a user who does not have a working extract: see the following
diagram.

A working extract inherits the write access of the parent access. That is if the parent is
primary at the location of the working extract than it can be written to, otherwise the user will
only have read access.
16.2.4 Extract Numbers

Before starting create extracts, work out an extract numbering system, and set the extract
numbers explicitly when the extracts are created.
Extract numbers must be between 1 and 8191 inclusive, for each database. The user must
set the range of extract numbers available for normal extracts, and for working extracts at
each location (see the diagram below). Do this by setting the EXTLO and EXTHI attributes
for LOCLI and LOC elements as follows:
• The available numbers for extract databases at a location are defined by the EXTLO
and EXTHI attributes for the LOCLI element under the /*GL element. The user must
define the range of extract numbers so that there are enough left for working extracts:
see next point.
• The available numbers for working extracts at a location are defined by the EXTLO and
EXTHI attributes for the LOC elements under the LOCLI element: for each Location
you must select a range of numbers which lies within the range you have left for
working extracts, and which does not overlap with the range for working extracts at any
other Location.
Note: To query extract number ranges by navigating to the appropriate element and giving
the commands:
Q EXTLO
Q EXTHI
When using the ADMIN menu bar, use the Location version of the Admin Elements window
to create or modify a Location. On the window, specify the range of numbers available for
working extracts at the location. Refer to Global User Guide for further information.
16.2.5 Reference Blocks

The allocation of reference numbers is controlled by the master database. Each extract may
be allocated reference blocks from the master. Elements created in the extract will be

allocated reference numbers from the local reference block(s). If no reference block is
allocated manually, the system will allocate reference blocks as required. For a Global
project, this may require daemon activity.
To avoid this, we recommend that the user should assign a block of reference numbers to
the extract when its created, using the REFBLOCK n option. The block of reference
numbers will then be available locally. n should reflect the number of users writing to the
extract, for example, if you expect to have five users writing to the extract, set n to 5.
Note: There are 8191 reference blocks available for each extract hierarchy, so there is no
need to be conservative when allocating them.
16.3 Setting up an Extract Hierarchy

Before starting create extracts and working extracts, have a clear plan of how they will be
used. The user should maintain diagrams of the basic master / extract / working extract
database organisation. These help when devising flush and release procedures, and
defining MDBs.
For project ttt:
Note: The databases shown are all part of the same extract family, and so they will all have
the same database number as part of their filenames, for example ttt0200_0001.
16.4 Using DACs with Extracts

The user can use Data Access Control (DAC) and Access Control Rights (ACRs) with
extracts and working extracts to control workflow. For detailed information about DACs, see
the ADMIN User Guide. When using DACs with extracts, the Aclass (Attribute Class) can be
set to restrict access to elements with particular attributes, which can include UDAs.

• Modify the ADMIN Module definition to give access to DICT databases using the EDIT
MODULE command in ADMIN as follows:
EDIT MOD ADMIN MODE DICT READ
• Set up an MDB containing the DICT database in which the UDAs are stored, and make
sure the user selects it on entering ADMIN. Users will also need to have read access to
the DICT database via their MDBs.
The following simple scenario illustrates how to use UDAs in Data Access Control
combined with extracts, to control workflow.
The Designer Role would give access to all Piping elements except those with the UDA
:ISSUED set to TRUE.
16.5 Using Extracts in MODEL

A useful querying command when using extracts in MODEL is:
Q DBNAME
This command will return the name of the database that you are actually writing to. If the
extract is a working extract, then the name of the parent extract is returned.
Another useful querying command is:
Q WDBNAME
This command will return the name of the working extract that you are actually writing to, if
there is a working extract. If there is no working extract, then the result is the same as for Q
DBNAME.

16.5.1 Managing Extracts

If the extract hierarchy has different primary locations for different extracts, then both the
parent and child databases must be both propagating and allocated at each other’s
locations. If this isn’t done then Claims and Flushes will fail.
Because of this, Claiming, Flushing, and Issuing should be managed by a Supervisor to
make sure Claims are handles in batches in a planned and controlled manner.
16.5.2 User Claims

Normal multiwrite databases require the user to claim an element before changing it. This is
known as a user claim. Depending on how the database is set up when it is created, user
claims can be implicit or explicit, and in either case, when a new element is created, it will be
claimed to the user who created it.
Note: In a Global project, we recommend that multiwrite databases should be created with
EXPLICIT claim mode, unless all the children are primary at the same location.
User claims can be explicitly released (unclaimed) by the user during a session, and
elements are always unclaimed when the user changes or exits from a module.
The commands for user claims are:
CLAIM . . .
UNCLAIM . . .
Extract Users can check daemon availability before claiming or flushing using the following
command line syntax:
Q COMMS (TO) <loc>
Q COMMS (TO) <loc> PATH
PING <loc>
Q ISOLAT AT <loc>
Q PROJ LOCK AT <loc>
These commands are now available in MODEL and other modules. This is particularly
useful to Claiming/Flushing, since commands fail if the connection is down.
16.5.3 Extract Claims

When using extracts, another type of claim, known as an extract claim, is made as well as
user claims.
• If an element is claimed to an extract, only users with write access to the extract will be
able to make a user claim and start work on the element.
• Once a user has made a user claim, no other users will be able to work on the
elements claimed, as in a normal multiwrite database.
• If a user unclaims an element, it will remain claimed to the extract until the extract claim
is released.
Extract claims allow persistent claims across sessions.
16.5.4 Command Syntax

The command syntax for handling extract claims in MODEL is as follows:
>- EXTRACT -+- CLAIM --------.
| |

|- FLUSH --------|
| |
|- FLUSHW -------|
| |
|- RELEASE ------|
| |
|- ISSUE --------| .-----<---.
| | / |
|- DROP ---------+-*- element -+- HIERARCHY -.
| | | |
| | ‘-------------|
| | |
|- FULLREFRESH --| |
| | |
|- REFRESH ------+--- DB dbname -------------+--->
|
‘- FLUSH RESET ------ DB dbname ----------------->‘
CLAIM Claims the element or the whole database to the extract.
FLUSH Writes the changes back to the parent extract. The Extract claim
is maintained. The extract is refreshed with changes that have
been made to its owning database.
FLUSHW Writes the changes back to the parent extract. The Extract claim
is maintained. The extract is not refreshed.
FLUSH RESET Resets the database after a failed EXTRACT FLUSH command.
(See note below under Flushing Changes.).
REFRESH Refreshes an extract with changes that have been made to its
parent extract.
FULLREFRESH Refreshes an extract and all its ancestors. A full refresh takes
place from the top of the database hierarchy downwards, ending
with a refresh of the extract itself. Each extract is refreshed with
changes that have been made to its parent extract.
ISSUE Writes the changes back to the owning extract, and releases the
extract claim.
RELEASE Releases the extract claim: this command can only be used to
release changes that have already been flushed.
DROP Drops changes that have not been flushed or issued. The user
claim must have been unclaimed before this command can be
given.
The HIERARCHY keyword must be the last on the command line. It will attempt to claim to
the extract all members of the elements listed in the command which are not already
claimed to the extract.
The elements required can be specified by selection criteria, using a PML expression. For
example:
EXTRACT CLAIM ALL PIPE WHERE (:OWNER EQ ‘USERA’) HIERARCHY

16.5.5 Extract Flush Commands Failing

Extract flush commands across a Global network may fail for legitimate reasons (see
Reasons Claims and Flushes can Fail for details), for instance, there is a naming clash (two
user's trying to issue a part of the same name; one will succeed, while the other will fail).
Normally Flush commands will be reset automatically by the system, allowing subsequent
Flush commands to proceed. In exceptional circumstances this may fail to happen - for
example if the Transaction database has been RENEWed. In such situations, the user must
reset the dB using the EXTRACT FLUSH RESET command.
Note: Under normal operation use of EXTRACT FLUSH RESET should be avoided. The
system will reset the dB automatically after a failed Flush.
16.5.6 Relationship between Extract and User Claims

If the databases are set up with implicit claim, when the user modifies the element, the
element will be claimed both to the extract and then to the user. If the element is already
claimed to the extract, then the claim will only be made to the user.
If the databases are set up with explicit claim, then the user will need to use the CLAIM
command before modifying the element.
16.5.7 How to Find Out What You Can Claim

This section explains what different users will see as a result of Q CLAIMLIST commands.
For this example, take the case of a database PIPE/PIPE, accessed by USERA, with two
extracts. Users USERX1 and USERX2 are working on the extracts.
USERA creates a Pipe and flushes the database back to the parent database, PIPE/PIPE.
The results of various Q CLAIMLIST commands by the three Users, together with the
extract control commands which they have to give to make the new data available, are
shown in the following diagram.

Note that:
Q CLAIMLIST EXTRACT
tells the user what can be flushed; and:
Q CLAIMLIST OTHERS
tells the user want cannot be claimed
To query the extract claimlist for a named database. The database can be the current one or
its parent:
Q CLAIMLIST EXTRACT DB dbname
When you create an element, it is only seen as a user claim, not an extract claim, until a
SAVEWORK. It will then be reported as an extract claim (as well as a user claim, if it has not
been unclaimed).
Note that a change in the claim status of an existing element will be shown by the
appropriate Q CLAIMLIST command as soon as appropriate updates take place, but a user
will have to GETWORK as usual to see the changes to the MODEL model data.
We recommend that:

• Databases that are going to own extracts which are primary at other locations, should
be created with explicit claim mode.
• Before you make an extract claim, you should do an EXTRACT REFRESH (or an
EXTRACT FULLREFRESH, if necessary) and GETWORK.
• If you need to claim many elements to an extract, it improves performance if the
elements are claimed in a single command, for example, by using a collection:
EXTRACT CLAIM ALL FROM !COLL
The Global daemon will only be involved in the claiming process if the user is claiming an
element from a secondary database / extract to their current primary extract. In this
instance, the user will be warned that the element is now being claimed by the Global
daemon. The user will know when the claim is completed, by using GETWORK and
checking the claim list.
16.5.8 Flushing Changes

When an extract user makes changes and saves them, they are stored in the extract. These
changes can be made available to users in other extracts using the EXTRACT FLUSH
command.
The FLUSH command operates on a single element or a database or a collection of
elements. The changes to these elements will be made available in the parent extract.
If changes need to be made available in the master database, it will be necessary to flush
the changes up through each level of extracts. Users accessing extracts in other branches
of the extract tree will need to use EXTRACT REFRESH to see the changes (or EXTRACT
FULLREFRESH, if the user’s extract is part of a multi-level extract hierarchy and is itself
owned by another extract).
The following diagram illustrates the sequence of commands that need to be given so that a
user working on extract B2 will be able to see the changes made by a user working on
extract A2.
The Global daemon will only be involved in the flush process if the user is flushing changes
to a secondary database / extract from their current primary extract.
Note: If a flush fails, the database needs to be reset to allow subsequent Flushes and
Refreshes to work. This is normally done automatically as part of the Global Flush
command. In exceptional circumstances, the EXTRACT FLUSH RESET command
may be used to undo the failed flush. However this will not normally be necessary.

This situation can arise when more than one user is issuing the same database extract.
Flush and release commands might then be processed in the wrong order, causing a flush
to fail and preventing subsequent refreshes of the extract.
16.5.9 Releasing Claims

Elements that have been claimed to an extract will remain claimed to that extract until they
are released. Any changes must have been flushed to the parent extract before the extract
claim is released.
The EXTRACT RELEASE command operates on a single element or a database or a
collection of elements. The elements claimed will be released from (that is, no longer
claimed in) the current extract, at which point they will be claimed by the owning extract.
If elements need to be made available in the master database, it will be necessary to
release the elements up through each level of extracts.
• The Global daemon will only be involved in the release process if the user is releasing
elements to a secondary database / extract from their current primary extract.
• When flushing / releasing data from a satellite to another location, check that the flush
has been successful before releasing the changes.
16.5.10 Issuing Changes

The ISSUE command is simply a combination of FLUSH and RELEASE.
16.5.11 Dropping Changes

The user can drop changes that have not been flushed. The EXTRACT DROP command
will operate on a single element or a database or a collection of elements.
• An element cannot be dropped if it owns new significant elements. List all the elements
in the same EXTRACT DROP command, or drop the lower-level elements first.
• The user must UNCLAIM any user claim on an element before it can be dropped.
• The DROP command should be used with care. Once the changes have been dropped
they can only be retrieved using session data or from backup.
16.5.12 Refreshing an Extract

If changes have been made to the data in an extract, the changes will not be visible in lower
extracts unless these extracts are refreshed. The REFRESH command operates on a
database, and it refreshes the database to look at the latest state of the parent extract.
If the changes are in the master and need to be made available in an extract several levels
down, the FULLREFRESH command should be issued at the extract. This refreshes each
extract in turn, starting with the extract directly beneath the master database, continuing
down to the lower extracts, and ending with a refresh of the extract itself.
Note the difference between GETWORK, REFRESH and FULLREFRESH:
• GETWORK will get changes made to databases in the current MDB.
• REFRESH will get changes made to the parent extract only of an extract in the MDB.
• FULLREFRESH will get changes made to all the extract ancestors of an extract in the
MDB.
The REFRESH command will only refresh from databases local to the satellite.
Therefore, if a secondary database has not yet been automatically updated with

changes made to the database at the primary location, then these changes will not yet
be visible at the local satellite. Extracts below the database will only see the latest
version of the secondary database when they are refreshed. To see the changes made
to the primary database, wait for the next scheduled automatic update before
refreshing.
16.6 Partial Operations

When named elements are specified in an ISSUE, DROP or FLUSH command, it is known
as a partial issue, drop or flush. There are some restrictions on what the user can do, as
follows:
• Where a non-primary element has changed owner, then the old primary owner and the
new primary owner must both be issued back at the same time. Otherwise there is
potential for inconsistencies to occur.
• If an element has been unnamed, and the name reused, then both elements must be
flushed back together.
• If an element and its owner have been created, then:
• If the element is included in a partial flush, then its owner must also be included.
• If the owner is included in a partial drop, then the element itself must be included.
• If an element and its owner have been deleted then :
• If the element is included in a partial drop, then its owner must also be included.
• If the owner is included in a partial flush, then the element itself must be included.
The HIERARCHY option will scan elements in both the extract and owned extract. Thus
deleted/moved elements will be included as part of the issue/drop/flush.
The user can use selection criteria to specify partial issues and flushes.
Deleted elements will be issued/dropped/flushed when the owning element is issued/
dropped/flushed. Alternatively the reference number of the deleted element may be given in
the ISSUE/DROP/FLUSH command.
16.7 Extract Sessions

When an extract is created, it is created at a particular session number in the parent extract.
This is called the linked session. As the owner extract is modified, and new sessions
added, the linked session on the child extract will not change until a refresh or flush is made.
Note that ISSUE, DROP and FLUSH cause an automatic refresh.
The following example illustrates how extract session numbers and linked session numbers
change as an extract is created and modified:
Extract session Linked session Comment

no. in owner
1 10 Extract created
2 10 Modification made on extract
3 10 Modification made on extract
4 15 Refreshed from owner (sessions 11 to 15 created by
other users).

Extract session Linked session Comment

no. in owner
5 15 Further modification.
6 18 Issued (sessions 16 and 17 created by other users)
7 18 Further modification
8 18 Further modification
9 25 Issued (sessions 19 to 24 created by other users)
While a user is making changes only to the extract, the linked session number in the owner
stays the same. On refreshing, the local extract is linked to the most recent version of the
parent extract.
The new session number linked to in the owner depends on the number of flushes done by
other users. In the example the linked session number goes from 10 to 15, indicating that
five flushes have been made by other users in the meantime (assuming that no work is
being done directly on the owner).
16.7.1 Merging Changes

When a MERGE CHANGES command is given on a DB with extracts, all the lower extracts
have to be changed to take account of this. Thus doing a MERGE CHANGE on a DB with
extracts should not be undertaken lightly.
The following restrictions apply:
• Any sessions linked to owned extracts must be preserved.
• There may be no users on any lower extracts.
We recommend that the user should MERGE CHANGES at the lowest level of extracts
first, and then work up the tree.
In a Global project, MERGE CHANGES can only be carried out at the location at which the
database and all its descendant extracts are primary. The REMOTE MERGE command
currently only handles leaf extracts and databases which do not own extracts.
See Merging Extract Databases for more information on merging extract databases.
Note: BACKTRACK is not allowed for extract databases. REVERT must be used instead.
16.8 Deleting a Database that owns Extracts

Deleting Databases, describes how to delete a database in a Global project, but the
procedure is different if the database owns extracts. The conditions required to de-allocate
and delete a database are quite complicated:
• To create, delete or modify a working extract at a satellite:
• the parent database of the working extract must be primary at the satellite
• To de-allocate a database from a satellite:
• The database must not be primary at the satellite
• The database must not own working extracts at the satellite
• To delete a database:
• The database must not be allocated to any locations other than the Hub

• The database must not own any extracts, either working or standard ones
Thus to delete a database that owns extracts (and may own working extracts) may
involve doing a number of CHANGE PRIMARY commands to get rid of any working
extracts at satellites where the database is secondary.
The procedure for deleting a database that owns extracts is summarised in the diagram
below.
No Is the DB
allocated to a
location?
Yes
No Is the DB
primary at a
location?
satellite
Yes
Make sure no one is

No accessing the db at the
Does the DB
own Extracts? location.
Yes
No Are they Wait for this command to

Working complete. Check as follows:
Extracts? GETWORK
Navigate to the DBLOC of the
Yes DB:
DBLOC 1 of dbname
DELETE extract tree DELETE the working Q ATT
The DB is primary at the hub
from DB you wish to extracts at the location where
delete. the DB is primary. when the LOCRF is set to the
Hub and the PRVRF is unset.
Change the db to be primary at hub.

CHANGE dbname PRIMARY AT hub
Check that this command

De-allocate the db from all the locations: has completed. The db is
DEALLOCATE dbname AT loc de-allocated when it is
removed from the location
DBALL list.
DELETE DB dbname
Note: A DB does not need to be primary at the HUB, just as long as it is not primary at the
location where it is being de-allocated

16.9 Variant Extracts

Variants are a special type of extract, with less rigorous control of claiming elements and
writing data back to the owning extract. They are designed to allow users to try out different
designs, which then may or may not be written back to the master.
Variants are different from normal extracts (including Working extracts) in the following
ways:
• Any element can be modified without being claimed, and so different users can modify
the same element in different variants.
• When data is written back to the owning database, it will overwrite any conflicting data
in the owner.
A variant can have normal extracts created from it. Note that in this case, the variant forms a
new root for claiming elements: claims in extracts below the variant will not be visible from
other parts of the extract family, and claims in other parts of the family will not be visible in
extracts owned by the variant.
If a variant extract is owned by a normal extract, then data must be claimed to the owning
extract when flushing from the Variant. This will be done as part of the Flush command from
the Variant, and the Flush will fail if not all elements can be claimed.
It is possible to have working variants.
16.10 Reasons Claims and Flushes can Fail

Claims and flushes may fail for valid reasons. If a flush has failed (e.g. due to a name clash),
all subsequent flushes will stall (Previous flush failed) until the failed flush has been reset.
Claims are treated as failing unless all elements have been claimed. Thus if 10 claims have
succeeded and 1 has failed, the Claim command is treated as having failed. The Extract
Control form in DESIGN, DRAFT and other modules contains more detailed reporting.
Here is a list of some common symptoms and the underlying causes:
Symptom Cause
Unable to savework. Perhaps you have Daemon has been expunged. Modifications
been Expunged to database (other than updates) will fail.
Flush may have overtaken another flush. In this case, the Flush will stall for a retry.
Previous flush could not be found
Previous flush failed Subsequent flushes will fail until failed flush
has been reset.
Unable to claim <item> because element is Valid failure - another extract or user has it
already claimed by <extract or user> from claimed
Extract <no>
Unable to claim <item> from parent extract EXTRACT REFRESH is required, to bring
<no> because element is modified in a later the child extract’s view of the parent up to
session. date
Nothing to claim locally - all claims failed in Cannot claim to child extract, because
owning extract failed to claim anything from its parent

Symptom Cause
You cannot claim <item> without doing an The item has not been claimed into the
extract claim from the parent extract extract before the User has claimed it. This
is only applicable to Explicit dBs.
Unable to claim <item> from parent extract The item has been deleted in the parent,
<no> as element has been deleted in a later and the child extract has not been brought
session up to date yet.
Element reference <item> is invalid or has The reference number of <item> cannot be
been deleted found in the database, it is an invalid
reference number.
Element <item> has been modified, so The item must be saved the database
cannot be released. Savework must be before an extract operation can be
done first undertaken on it.
Element <item> has been deleted by The item you are trying to Claim has been
another User deleted by another user.
Name clash on <item>. Please rename The name of the item that has just been
created already exists.
Cannot flush/abandon <item> as old and The parent of the owner has been changed.
new owners must both be in the list, or Both the old and the new owners need to
neither in the list be flushed/issued/abandoned at the same
time, and the list currently only contains one
or the other.
Cannot flush/abandon <item> without its The item is either new or moved to a
owner another item. Both need to be flushed/
issued/abandoned at the same time.
Cannot flush/abandon <item> without its The member list of item has changed in
members some way. The item needs to be flushed/
issued/abandoned with its members.
Cannot abandon/release <item>. Element is The item is claimed by a User (possible the
claimed out by a user (maybe yourself) or to user doing the EXTRACT ABANDON/
an extract RELEASE) or to a child extract.
Element <item> kerror <no> Internal error. Please contact AVEVA
support desk for more information.
Dabacon error <NUMBER> for DB <item> Internal error. Please contact AVEVA
support desk for more information.


Off-line Locations
17 Off-line Locations
Normally there is a communications link between pairs of locations, and these locations are
referred to as on-line. (Their ICONN attribute is 1, and RHOST points to a valid computer
name.) However, Global can operate if there is no direct communications link between the
Hub and certain locations. These locations are referred to as off-line. (Their ICONN is 0,
and RHOST may be unset.)
A tape, CD or other medium is used to copy the databases from one location to the other.
It should be noted that:
• The TRANSFER command copies databases to or from the project directory to a
special transfer directory, ready for the physical transfer to another location. The
physical transfer must be made as well as using the TRANSFER command from
ADMIN.
• The existence of off-line locations limits the administration capabilities of a project.
• Off-line locations can only be children of the Hub. An on-line satellite cannot have off-
line children.
• Database transfer to and from the media used for communication with an off-line
location can only be made at the Hub and the off-line location.
• Commands such as ALLOCATE and CHANGE PRIMARY are not self-contained.
Working practices are required to make sure the correct transfer of data.
17.1 Working Practices with Off-line Locations

The following list highlights practices that should be observed:
• All users must exit before the TRANSFER TO command is initiated. Otherwise, the
command may fail.
• To make sure that the database file is copied to the satellite when a new database is
allocated to an off-line location, the TRANSFER TO command must be used at the Hub
after the ALLOCATE command. The TRANSFER FROM command is then used at the
satellite. The TRANSFER should precede a CHANGE PRIMARY command.
• Before a CHANGE PRIMARY command to or from an off-line location is initiated, all
users of that database should exit. TRANSFER TO (at the old primary location) and
TRANSFER FROM (at the new primary location) must be used to make sure the
database is up-to-date. The CHANGE PRIMARY command may then be issued. This
should be followed by a TRANSFER TO command (at the Hub) and a TRANSFER
FROM command (at the off-line location).
• Extract hierarchies must never be partially off-line. An entire hierarchy must be on-line
or off-line.
• Working extracts cannot be created for off-line locations, unless they are self-
administered. (The file for the working extract cannot be created if the Hub administers
the off-line location.)

Off-line Locations
• Transfer of other data, such as ISODRAFT files, external PLOT files and MODEL
manager files, must be done manually to an off-line location and from it.
• To change a satellite from on-line to off-line, shut down its daemon and change ICONN
to 0. Manually copy the Global database to the off-line location. The TRANSFER
command will then work.
• Picture Files and DWG files are transferred to Offline Locations and should be copied
on CD/through ftp when they reside in the locations Transfer area.

Firewall Configuration
18 Firewall Configuration
The primary objective of a firewall implementation is to provide security to an organisation’s

network. In simple terms, a firewall solution enables only certain applications to
communicate from ‘the outside world’ (for example the Internet) to the organisation's
network, and vice versa. To enable these applications to function, specific ‘communication’
ports need to be open. The fewer ports open within a firewall, the less chance there is of
security breaches.
Under situations where Global is implemented within an environment that has no firewall set
up, Global will function without any specific network configuration (other than the
requirements outlined under Global > IT Configuration on the AVEVA Support website and
in the Global User Guide). However, when a Global project is to be deployed between two or
more locations that have firewall implementations, certain ports need to be open in order for
Global to function.
18.1 WCF Port Usage

RPC communications can be used to transmit Global data. Global uses TCP port 135 and a
dynamic range of ports above 1024 to communicate from one location to another if RPC is
used. (i.e. through the Global daemons running at each location).
The dynamic range of ports required to be open (i.e. 1024 and above) poses a security risk.
In order to reduce this, we can force the operating system’s RPC communications to use
only a specified range of ports. This drastically reduces the risk of intrusion from third
parties.
When WCF is enabled as the security provider the user has full control over the ports used
for network communication. Port usage is specified inside configuration files described in
the Global WCF Configuration Guide.
The ports specified in the configuration files must be opened for bi-directional traffic on the
Firewall.
Additionally firewall rules can be specified to limit access to ports used by a specific
program. Global has a unique identifier (UUID) which can be used when defining a firewall
rule. For further details contact AVEVA Support directly.
18.2 Limiting Ports Used with RPC Communication

It is possible to limit the destination port that RPC uses when communicating with another
machine. The source port used will still be in the range >1024, but for security reasons
firewalls are primarily only concerned with destination ports.
The Ports value specifies the range of ports that RPC will use, in this case 20 ports, ranging
from 5000 to 5020. The user will need to configure on all systems running the Global

daemon across a firewall. On Windows, a reboot of the system is required after registry
modifications.
Once the RPC ports are defined, the firewall can be configured. As shown below, the
firewalls for both organisations are opened to allow only communications to and from each
other’s Global Servers on TCP ports 135 and 5000-5020.
These ports must be opened bi-directionally to allow Global to operate. It is possible to limit
access to these ports using the UUID for Global;
d2af263a-b21d-1001-8e31-0800690811cc
(this is not the same as the project UUID).
The following solution can be applied to any modern firewall with the functionality of packet
filtering.
The procedure for restricting the use of dynamic ports for RPC is through additions in the
Microsoft Windows registry.
Note: Incorrect modification of the registry can lead to serious problems. Always back up
the registry before making changes.
To change the registry, the user must use REGEDT32 and not REGEDT, as the latter does
not allow modification of the string data type. If REGEDT32 is not used the following
message will appear on daemon startup:
Can’t establish protocol sequences: Not enough resources
are available to complete this operation
The user must add a subkey and three values to the registry.
Under the following key, add a subkey called Internet:
HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc

This results in the registry key:-

HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet
Under the Internet subkey create three values with the corresponding string data -
displayed in the Registry Editor as:-
"Ports" (type MULTI_SZ):5000-5020
"PortsInternetAvailable" (type REG_SZ):Y
"UseInternetPorts" (type REG_SZ):Y
Note: When entering the three strings DO NOT enter the colon before 5000-5020 and Y
entries. If the colons are added the global daemon batch file will abort with the
following error
Can't establish protocol sequence: The parameter is

incorrect
The edited registry should now look something like this:
Note: The RPC configuration procedure described in this document can also be found in
Microsoft TechNet Knowledge base: Article number: Q154596. Note that Microsoft
recommend a minimum of 20 ports to be open for other services; for more
information on this please refer to the article which is available on the Internet at
http://www.microsoft.com/technet. The number of open ports suggested in the
example above is just that: a suggestion. However it is generally true that the more
Global projects you are using, the more ports you are going to require to be open.


Suggested Housekeeping Guidelines for Projects
19 Suggested Housekeeping Guidelines for

Projects
This Section gives general advice on the “Housekeeping” activity for Administrators running
projects. We use the term “Housekeeping” as a metaphor to compare the work you would
perform to create and maintain a house and its contents in a state of good repair, well
organised, tidy and clean with the similar goals for the data of an engineering project.
Similarly to a house, the larger the scale the more substantial a task this can be. However, if
you establish the basis and practices early, you can keep the task to a routine activity that
increases in efficiency with practice over the duration of the project.
This Section should be seen as supplementary material to the standard Administration
documentation and not a replacement.
As with all advice it is not mandatory and should be taken as points for consideration in
creating a stable Administration environment. Also, although efforts have been made to be
as comprehensive as possible it is not exhaustive and will be subject to modification and
addition as the base product and its use across wide industry sectors increases and
experience in good practice improves to match.
It is written for an audience who are assumed to have undertaken training in Administration
and have a thorough background in maintaining projects. Moreover, not everything
described here necessarily applies to all project set-ups under all circumstances.
However, IT managers may find it useful as background information in deciding how to
organise base product Administration.
19.1 Dice
This is the Data Integrity Checking tool supplied as part of the ADMIN module.
Its purpose is to provide a report on the base product Dabacon databases that informs the
administrator if there are any issues with the database that require extra attention. In
addition, you can also run it in a “patch” mode that will actually facilitate a repair on the
database.
It is recommended that a full Dice report it is run as a matter of routine daily on all databases
in the project. This includes the full extract family and secondary databases if Global is in
use.
Foreign projects, such as a centralised Catalogue, should also be Dice checked, although
the frequency should not need to be so frequent if they are not being updated on a daily
basis. Often this is done as a scheduled batch routine during no working periods.

However, if the project is in a period of intense activity and the window for running bulk
processes for reports, drawings, material take-off is small, it can be run with users and batch
processes continuing to run on the model.
Having produced the report it is imperative that it is closely scanned for issues of concern
and then action taken to address them. Ideally, the Administrator should take action to
remove all errors and warnings; however some warnings can be deemed to be acceptable
and of no risk to the healthy running of the project e.g. Element =18585/38329 Warning-
Attribute TREF contains invalid ref =18585/74770.
This error will also be highlighted to the normal users as they check their designs so it will be
picked up there. However, if the identical reference numbers in these messages recur the
Administrator should follow up with the last user to access the element (info in session data)
to make sure it is cleared.
The Fatal Errors listed in a Dice report are usually ones that need immediate attention and
action to repair the database will be needed. Nevertheless, on occasion the error can either
be tolerated for a period as it is not truly critical, or may have been wrongly categorised as
Fatal and constitutes only a warning e.g. Error in level 2 NAME table, session no. 10469,
page no. 42385 - incorrect value of first key on lower level page no. 42386 (extract 1).
While AVEVA provide analysis of each error message outlining how it should be addressed,
the nature of an individual project set-up can make the method on how they should be
addressed variable. Therefore it is recommended that as the Administrator becomes
familiar with the action needed to address each warning or error it is documented and
recorded in project work instructions.
Certain database errors can be fixed by running Dice again against the problem database,
this time in “patch” mode to repair the fix. Two typical examples are:
Child extract 12 not listed on header page
Element SBFITTING /
SBFIT99 needs clearing from mainlist in header extract
This should normally be done when there is no Write access to the database. Even though
the Dice report will report the problem cleared, it may be a good idea to rerun a Dice full
check on the repaired db with “patch” mode disable to be 100% sure the problem is cured.
Other database errors can only be fixed by a Reconfiguration of the database. For example:
Element =35021/
13323 has an inconsistent entry in the name table. Name
exists on the element but is not in the name table
itself. Thus the element can not be navigated to by name
Please reconfigure this DB to resolve the problem
This work should be done when there are no Read or Write access to the database, but to
avoid a complete project shutdown it is possible to remove the problem db from all MDB’s
do the repair and then replace it. Because of the additional complexity this may involve,
looking for a window in the project workload is normally the preferred choice.
Two or three days before a phase of major deliverable production it is recommended to be
especially diligent in Dice checking to make sure that all databases are in good shape and
reduce the risk of an interruption in the bulk process.
If a user reports an unusual problem with part of the project data, such as a Dabacon crash,
the first step should always be to perform a Dice check on the database(s) involved. If the
report shows issues that cannot be repaired by patching or reconfiguration then the Dice

report should be sent immediately to AVEVA support.

If after repairing the database the database is OK for a few days and then Dice reports
errors again then this may indicate a deeper issue and the Dice report together with any
background information on circumstances that are common to the error occurring e.g. same
users, same UI menu etc. should be reported to AVEVA support who may then request that
the databases be sent in for fuller investigation.
19.2 Global
This section provides information to advise Administrators on good practices. We
recommend you read it fully.
19.2.1 Update Frequency

The idea of Global is that it provides the ability for a project split across several locations to
behave just as if it was located in one location. Therefore it is assumed that most
deployments of Global will have this objective in mind and will make sure that each location
is updated with changes from the other locations on a frequent basis, especially when they
are in similar time zones. This is particularly important when the locations are operating in
the same physical space e.g. in a compressor house one location covers the steam lines,
the other the utility lines. The aim here is, of course, to try and avoid routing pipe in the
same space as the other location. This also lies to the idea of keeping an Extract database
only local at one location i.e. if the project is process split this will incur a higher risk of clash
issues when the data eventually migrates to a higher level database shared between the
locations. If the project is split geographically e.g. each location covering complete units,
then this particular risk is reduced.
As a baseline updates between locations occurring around 4 times per working day are
reasonable with a possible escalation if significant change is occurring at critical times and
data is needed by one location faster than normal e.g. a fabrication yard when the project
data is reaching design completion. Examples of updates every 15 minutes have been seen
in this particular scenario.
Where the project is split across time zones, then timing updates to make sure data is
exchanged to suit start and close of work with attention to any time overlap is
recommended.
However, when selecting update frequencies the issue of data quantity moving across the
network should be considered too. The other idea of Global is to allow smaller chunks of
data to be transferred rather than whole databases. Therefore, if only one transfer is done
per day, the quantity of data will be large and if there has been an intense period of
modelling in one location then the update may take longer, possibly not completing in time
for drawing or review file production as expected. Therefore, doing several updates will
reduce the risk of update overlap or incompletion before deliverable production.
When different time zones are involved, it may be useful to use an intermediate satellite.
This will make it easier to transfer large amounts of data outside working hours.
19.2.2 Timing of Updates

The batches of updates that are run in one update session to keep all locations
synchronised do not have to be run sequentially. However, updates should be not started at
exactly the same time to avoid file-contention on the Global database.

If it is felt desirable to run the updates sequentially then a script will be required that uses
the EXECA and EXECB script attributes on the Update event (LCOMD) to run pre- and
post-execution scripts on a scheduled update. This could also:
• Record update start and finish times
• Report on Database sessions
• Lock out other updates by creating/deleting a lock file
This script is not a standard delivery as it needs tailoring for each project set-up. If
required the customer can request services from AVEVA to deliver this.
19.2.3 Checking Locations are Aligned

A simple check to make sure that locations are aligned is to run a macro which captures the
latest session number of each secondary database as compared to the latest session of the
Primary database.
NOTE: Such a macro could use the Q REMOTE command to query the remote location (Q
REMOTE <loc> <dbname> LASTSESSION). The session number can be extracted from
the query result.
Q REMOTE ABC MYTEAM/DESI LASTSESSION
Q REMOTE ABC MYTEAM/DESI FILEDETAILS
Assuming it is run when there are no users on the project then the session numbers at all
the locations should be identical, however if the Primary db is being used it is likely that the
Primary session number will be slightly higher than the Secondary databases. As the
intention is that Global runs while users are continuing to work this will be the most common
scenario.
If for some reason the Secondary database is higher than the Primary, detailed investigation
will be required to realign that database. An example of the type of output from such a
macro follows:
DBnumber DBname Session_ Session_ Session_ Session_

SAT1 SAT2 SAT3 HUB
2001 SAT1PIPING/UNITA P 1134 S 1128 S 1128 S 1128
2000 SAT1PIPING/UNITB P 684 S 679 S 679 S 679
2002 SAT1PIPING/UNITC P 106 S 106 S 107 S 106
2003 SAT1PIPING/UNITD P 758 S 742 S 692 S 742
2004 SAT1PIPING/UNITE P 533 S 517 S 467 S 517
2457 SAT3PIPING/UNITA S 1164 S 1164 P 1169 S 1164
2451 SAT3PIPING/UNITB S 814 S 793 P 849 S 814
2432 SAT3PIPING/UNITC S 131 S 131 P 133 S 131
2431 SAT3PIPING/UNITD S 451 S 451 P 453 S 451
2100 HUBPIPING/UNITA S 1148 S 1148 S 1148 P 1175
2102 HUBPIPING/UNITB S 212 S 212 S 212 P 213
2104 HUBPIPING/UNITC S 231 S 231 S 231 P 234
2355 SAT2PIPING/UNITA S 560 P 562 S 560 S 560

DBnumber DBname Session_ Session_ Session_ Session_

SAT1 SAT2 SAT3 HUB
2353 SAT2PIPING/UNITB S 288 P 328 S 288 S 324
2351 SAT2PIPING/UNITC S 513 P 578 S 484 S 541
2351 SAT2PIPING/UNITD S 79 P 101 S 79 S 79
2343 SAT2PIPING/UNITE S 174 P 176 S 174 S 174
• Legend
P Primary location
S Secondary location
Locations aligned
Secondary locations not aligned Update manually to synchronise
Secondary location ahead of Primary. Investigate and repair.
This macro is not a standard delivery as it needs tailoring for each project set-up. If required
you can request services from AVEVA to deliver this.
19.2.4 Change Primary - Repair Process

If there is a need to move the location of the Primary database the Change Primary
functionality should be used. However, it is important that the Change Primary operation
completes before Deallocate is done because the system will lose identification of where
Primary actually is and Deallocate will fail. The term Transient is used to describe this
scenario - ADMIN reports
(1,529) Cannot deallocate DB /*CTBATEST/ISOD at LOC /CAMBRIDGE - relocation
already in progress
The following recovery procedure is necessary:
• RECOVER <db> AT <primary-location> FROM <a selected secondary location>
• PREVOWN <db> - to recover its previous primary location
• Then CHANGE PRIMARY can be repeated
• Wait for its completion before issuing DEALLOCATE
19.2.5 Risks of Aligning Databases Across Locations by File Copying

On occasion if there have been unexpected interrupts in the Daemon service the Secondary
databases can become completely misaligned with the Primary databases. To repair this,
there is a temptation to simply delete the Secondary databases and file copy the Primary
database out to the secondary location. The risk in this is that, in spite of a very diligent
approach, human error can occur and there is a risk of reverse propagation i.e. a Secondary
database thinking it is Primary. In this scenario the Recover process should be followed.
See Change Primary - Repair Process.
Therefore if the Primary and Secondary databases do become broadly misaligned on the
project it is advised that realignment is done by executing the updates manually ensuring

each update process completes successfully and that the realignment has been successful
before kicking off the next update.
19.2.6 Flushing/Issuing
It is common practice for all users on a project that uses Extract databases, whether Global
or not, to follow common practices of Flushing. Generally it is expected that each user will
be expected to Claim, Flush and or Issue on an object-by-object (or small group of objects).
However, it may be decided by some customers to manage the Flush and Issue on a
collective basis at managed intervals, say once a day. If this is done then the Flush or Issue
should be done at as high a level in the database e.g. SITE. This reduces both the number
of sessions created and the database file size.
Note that if the Model Object Manager software is in use, the program does background
flushing and issuing to keep the Primary data as synchronised with the Oracle data as
possible. If Model Object Manager is in use regular Global Updates will also reduce the risk
of the user viewing Oracle data that is not synchronised.
19.2.7 Transaction Database

This database holds all the information about the success or failure of the updates and
remote claiming and is the first place to go to check that Global is operating successfully.
Ideally it should be regularly monitored by the Administrator responsible for each location.
Note that if an automated update fails for any reason, then there is always the option to
perform the update manually rather than waiting for the automated update to try and align
things again. By doing the update manually, the duration of locations being out of synch is
reduced and also the automated update process does not get loaded with 2 or more lots of
update data to deal with.
On a large and busy project the transaction database can become very large, so it should
be compacted on a regular basis. The recommended method of doing this is to use the
Merge-and-Purge process via the Daemon.
Daemon merge-and-purge can be done when MODEL users are in the project (but not
ADMIN users) provided that they do not have the Transaction db in their MDB. If a Module
(e.g. ADMIN) is accessing the transaction db when the merge-and-purge is attempted, then
nothing will be purged.
However, if the merge-and-purge is interrupted e.g. by a crash of the Daemon, then one of
the two following methods could be used at each satellite after all users are out of the
project and the Daemon has been stopped: either
• carry out a normal merge (merge changes TRANSACTION/SAT). It will be necessary
first to run a macro to collect and delete old commands -otherwise the merge will
achieve nothing. AVEVA can assist with writing such a macro. An example of a similar
macro you can use as a basis is shown in Example Macro for Collecting and Deleting
Old Commands.
or
• rename the database (eg. ABC0001_0001 to ABC0001_0001-ORI)
• restart the Global daemon ( a new clean database will be created automatically)
The problem with this method is that incomplete transactions are lost and therefore
updates are missed and this may contribute to misaligned Primary and satellite
locations.
The ADMIN UI provides a view of the updates from the Transaction db and it is important
that the administrator checks the actual messages from these Updates because the update

may not have successfully updated ALL databases, although the overall command has
been successful.
If the MESSAGE reads 'Update All succeeded (NNNN DBs) with MMMM failures' then the
administrator MUST investigate the failures. The FAILUREs pane of the Transaction
messages form indicates this. If this check is considered to be worth separating to a distinct
procedure a macro may be written to collect TRFAIL elements below the TRINCO for the
TIMEDUPDATES user.
19.2.8 Daemon Log File

If the Global Daemon crashes unexpectedly there may two types of cause; 1. An
unexpected problem with the databases that is not being picked up in Dice or 2. An IT
infrastructure issue. To determine which, a log file can be activated via a system
environment variable (evar) that will capture detail of all Daemon activity, particularly exactly
what was happening leading up to the crash. The evar is DEBUG_ADMIND - see chapter 4.
Output from the daemon should be piped to a file.
This log file should be sent together with the Transaction db & Global and System dbs for
Hub and satellites to the AVEVA support desk who can work with R&D to determine
whether it is 1 or 2. If 1 then a repair can be advised on the problem database and/or a fix in
code to prevent it recurring can be deduced. If 2 then further investigation in what was
happening in the IT infrastructure needs to be done by the customer. Some evidence may
be found in the Windows System Event Log which should also be shared with AVEVA to
help isolate the issue.
The log file can grow quite large if left running for a period so it should be cleaned down
daily by renaming it during a period of Daemon inactivity with a time and date stamp which
means that when the Daemon restarts a new file will be created. Should holding the
renamed file on disk be a problem on space it can be archived off and deleted.
19.2.9 admnew Files

When the Daemon copies a Database usually after a session Merge (as opposed to a
session-based update), it copies to a temporary file with the suffix .admnew. When the copy
is complete, this file is renamed to replace the old database file.
These .admnew files are normally tidied up automatically. However, if the daemon has
crashed, it may leave unwanted .admnew files behind, which can prevent a subsequent
Daemon attempt to copy the database from running.
Make sure that the satellites and hub remove such files after a crash.
See admnew Files for a full description of .admnew files.
19.3 Session Management - Merging

It is recognised good practice to reduce database file size on occasion and this can be done
using the Merge functionality to compact the session data. The frequency of the merge is
dependent upon the activity in the db and its rate of growth.
On a Global project it should be remembered that after a Merge on a Primary database the
updates will transfer the whole db anew to the Secondary locations. Because of this the
update will take longer than a simple session update and it is therefore recommended to be
done at a weekend.

Merge has to be done at the Primary location unless a Leaf extract organisation has been
used where the Remote Merge functionality can be used from the hub. Remote Merge can
be done with the Daemon running, but for normal Merge operations it is recommended that
the Daemon is stopped to prevent any updates occurring. The steps to be taken prior to a
merge are covered more thoroughly in the Database File locks section of this document.
Note: A Leaf extract is a database which does not own other database extracts.
19.4 Database File Locks
19.4.1 Background
On occasion there may be circumstances where after a piece of Administration work such
as session merging, the database file has been found to be locked by the Windows
Operating System. To resolve file locks, the Administrator has two options:
Reboot the computer where the databases reside (this assumes the Administrator has the
privilege to do this, for a lot of cases this is not a practical solution).
Resolve file locks using a specific tool as described in admnew Files.
Also note that if the project is not used as a foreign project, you have a third choice in the
Overwrite DB Users flag, which is the LCPOVW attribute of the LOC element.
This attribute controls whether a ‘locked’ file at a location may be overwritten. If this attribute
is set TRUE and there are no database READERS in the project, then Global will overwrite
the ‘locked’ file by the .admnew file.
Important: Do not do this if other projects include this database as a foreign project, since
these are valid READERS that are not recorded in the session data for the
Global project.
19.4.2 Avoiding Random File locks

Do not exit Modules illegally. Make sure ALL users are aware of and follow the instructions
below:
Exit cleanly through a Module GUI or using FINish from the Command Line.
• Do not kill (“Close” via top-right X button) the background DOS window.
• Do not kill the main Module Windows and then directly re-enter that Module. If for some
reason this has to be done then use the Windows Task Manager to check that the
Module process has closed and if it has not then “End” the process.
19.4.3 Locating and Closing Locked and/or Open Database Files

Before performing any ADMIN work on databases such as session merging or
reconfiguration, it is important that there are no users accessing the database and that the
database file is closed.
• Removing Users
After a session has been illegally exited, either deliberately or due to an unexpected system
fault, the Users who were accessing the databases may be left as phantom users (also

known as dead users) in the system. To clear these users from the databases and release
their claims the Administrator can use the Expunge syntax for all users or specific db’s (see
ADMIN Command Reference manual for details of all Expunge options, including how to set
the Overwrite DB Users option to allow non-foreign projects to copy over locked files
provided there are no users recorded in the COMMS db. Overwriting is disabled by default
because it may cause sessions of “dead” users to crash).
You can use the ADMIN Module for this also.
To force live “rogue” users out of the system who have not followed the request to leave the
system before Admin work is carried out, the Expunge User Process can be used. This will
not stop the process on the Workstation but it will sever the link with the database file and
the next time the user tries to access the process (Module Window) it will crash. After the
Expunge User Process has been done it is common practice to then use Expunge All Users
to remove any lingering phantom users and release all claims.
However, it is necessary after the Expunge processes (or other illegal exits) to make sure
that the database files have not been locked by Windows or left open and they should be
closed so that further work in the databases can be done. As the files normally reside on a
separate File Server, administration access to that server will be required.
• Managing Database File Status

To monitor for locked and/or open files the Windows's own Open Files screen on the File
Server can be used. However, there is no standard Windows tool to close the locked or
open files and additional utilities are needed. The utility used by AVEVA and other
customers is pstools that can be obtained from Sysinternals the specific tool being PsFile.
Using this, the files can be monitored and closed.
Note: PsFile only shows files opened remotely, so won't show files open by processes
running on the File Server itself - e.g. if scheduled jobs are being run on the File
Server itself.
Alternatively, you can use the Microsoft NETFILE API on the server to free locked db files.
Summary of steps before conducting an ADMIN task on a database
1. Broadcast a message to all users on the project telling them that they should cleanly
exit by a required time. If the ADMIN MESSAGE command is used note that it will only
be visible to those logged in at the time, and when they change module.
2. At the advised time Lock the project via ADMIN to prevent any users accessing the
databases further.
3. If a Global project, stop the Daemon to stop updates and/or remote claiming.
4. Check the project for any users still logged in and try to get in contact with them and
ask them to leave the project cleanly.
5. Any users who cannot be contacted should be severed from the project by Expunge
User Process.
6. Expunge All Users to remove any phantom users and release any claims.
7. Using pstools PsFile check for any open or locked db files on the db File Server.
8. Using pstools PsFile close any open or locked db files on the db File Server.
Note: In truth the only databases that should not be being accessed in the project in Read
or Write mode are those on which an ADMIN task such as reconfiguration or session
is being undertaken. However to secure this without getting all users out of the
project is to isolate the databases (inclusive of the whole extract family) from use by
removing them from all MDB’s and then performing steps 1-8 with the exception of 6.

Deferring them is not recommended as the user can overwrite the deferral. After the
Admin task has been performed on the specific databases they can then be re-
added to the MDB’s.
As this adds an extra level of complexity to the Admin task it is therefore suggested that a
window of time is sought where the whole project can be shut down.
19.5 Distributed Extract Hierarchy

Where work needs to be execute on one database by two locations a Leaf Extract
organisation is required. Below is a sketch that outlines how in a 2 level extract organisation
this should be set up:
In this scenario the SAT2 users working on the EX2_SAT1 db are claiming objects from EX1
Primary at SAT1.
This can be done dynamically in Explicit Claim mode over the Daemon. However, the
response can be variable causing the SAT2 users to be unsure as to the status of their
claim. Therefore it is recommended that the project is organised in such a way that the EX1:
Primary objects to be worked on at SAT2 are identified and marked by the SAT1 users and
then an Admin process is run to Extract Claim the collection to the EX2_SAT1 Primary db at
SAT2. When the work on the objects is complete the SAT2 users mark the objects as ready
to be Issued and an Admin process is run to Extract Issue the collection back to EX1:
Primary.
19.6 Project Administration Team

Each customer has its own internal organisation for the management and coordination of IT
systems. However, experience shows that if the Administration roles for a project are not
firmly established, especially across multi-location Global projects, then the “Housekeeping”
activity can become disjointed and the project may suffer downtime whilst repair work has to
be undertaken in normal working time. The aim is to keep coordination and decision making
streamlined with a minimum overhead of debate and dialogue.
AVEVA suggest the following for a major project:

19.6.1 ADMIN Lead

A single technical expert, with an in-depth knowledge of the application from a User and
Administration background is placed in charge of the whole project, has decision making
authority and is the contact for communication with the engineering and IT management for
the project. This person is to have a full-time Deputy who can stand-in in their place during
planned and unexpected absence. In a Global project the location of the Hub should be
sited at the location of this person.
This role, including the Deputy, should have a high-level of IT knowledge and be a trusted
partner of the IT group with permissions to access the application server(s) to perform
specific tasks.
It will be this role that has the main contact with AVEVA Support unless it pertains to a
specific discipline need when the Discipline SME role comes into play.
This is a full-time role on a major project.
19.6.2 Discipline SME’s (Subject Matter Experts)

Each major discipline to have a nominated SME who coordinates all discipline activities with
the ADMIN Lead and other SME’s. This may include a Catalogue and Spec SME who
performs the specific task of servicing the Discipline SME’s with skills for this specialist area.
The SME should have a high level of expertise at a User level with a firm understanding of
the principles of projects. If the project is Global it is still suggested that a single SME is
nominated for each discipline in order to maintain a common project approach.
Depending on project scale and level of discipline activity, within the team of Discipline
users there should be trusted senior users who can stand-in for the SME in the event of
absence.
For Discipline specific issues this role should be in touch with a discipline SME counterpart
in AVEVA Support.
This is a part-time role on the project. Activity intensity on specific issues will vary with the
project schedule. At project start it is most likely to be a virtually full-time role for the opening
weeks, moving to an irregular pattern of high and low workloads to be balanced with the
primary role of engineering and/or design on the project.
19.6.3 Global Satellite Co-ordinator

On a Global project it is recommended that each location nominates a senior user from the
project to act as the local Administrative support for Global. This role reports to the ADMIN
Lead. Ideally the person fulfilling this role should have both end user and Administrative
experience and also have a high-level of IT knowledge and be a trusted partner of the IT
group with permissions to access the application server(s) to perform specific tasks under
the direction of the ADMIN Lead.
Depending on project scale within the team of users at the satellite there should be trusted
people who can stand-in for the Global Satellite Coordinator in the event of absence.
It is not expected that this role will need to contact AVEVA Support directly as issues should
be escalated through the ADMIN lead or Discipline SME’s depending on the topic. However,
where there are time-zone issues this may change to make sure contact with local AVEVA
support is established.
This is a part-time role on the project following a similar pattern of workload to the Discipline
SME’s.


Project Setup Guidelines
A Project Setup Guidelines
For a standard project setup refer to Chapter 5 of the Administrator User Guide. There is an
extra project setup for Global which is:
• Set up environment variables for location transfer directories. The environment
variables must be added to the {proj}evars.bat file in the project folder.
set {PROJ}_HUB=C:\{your project path}\TRANSFER\HUB
set {PROJ}_PFB=C:\{your project path}\TRANSFER\PFB
etc.
These will contain the project directories.
Launch base product and at the login screen make sure that the project that is to be made
Global is selected in the login page. Then from the login page make sure that the Admin
module is selected.
In the Admin module select Display > Command Window.
At command line type the following commands in sequence:
• Lock
• make Global
Note: The user will be prompted to close and re-open the Admin module.
• unlock
• savework
Then quit the Admin module and reload as prompted.
Note: When re-starting the Admin module a prompt will inform the user that the Location is
uninitialised.
In the Admin module select Locations from the Elements pulldown and highlight /projecthub.
Click Modify and rename /projecthub to /hub then click Apply.
A prompt will ask if the user wants to initialise the location. Click Yes.
A prompt will be displayed indicating that a new transaction database has been created.
Click OK then Dismiss on the Modify Location window.
Start the Global daemon by typing the following from the Windows command line. Click
Start > Run and then type CMD to open a Windows command line window.
C:\AVEVA\Global{version}\admind start {proj}
To verify that the command has run successfully the user can query the linit flag of the
location. To do this:
© Copyright 1974 to current year. A:1 12 Series

• Open the Admin module.

• Select Location from the Element pulldown.
Select Display > Command Window to open the command window and then type the
following commands
q linit
Example PML to wait for command to complete:

!c = curloc
do
pause 1
session comment 'Interim savework at HUB after INITIALISE'
savework
getwork
break if (!c.linit)
!f = object FILE(!!itaSkipPath + '/skip')
break if (!f.exists())
skip
enddo
savework
***** Generate the locations at the HUB ******
/*GL
LOCLI 1
NEW LOC /PFB
LOCID ‘PFB’
DESC ‘Piping Fabrication’
RHOST ‘sg132’
CR DB TRANSACTION/PFB
GENERATE LOCATION PFB NOALLOCATE
Note: ALLOCATE will copy all the project files to the location defined by variable
{proj}_PFB.
NOALLOCATE will only copy the system DB files.
At the Satellite, use Windows Explorer to copy the files in {proj}_PFB to the location
directory where the project will reside as {proj}000 (i.e. the Satellite).
Set up the base product environment at the satellite location (executables, Project
directories etc).
• Set up the base product environment at satellite location (executables, Project
directories etc.)
set AVEVA_DESIGN_EXE=C:\ita_test_env\E3D
set {proj}000=C:\net\project\{proj}000 …..etc.
• Start the daemon at the location PFB
%AVEVA_DESIGN_EXE%\admind start {proj}
AT LOC PFB

• If still in the base product at the HUB, check PFB daemon by

PING PFB
Example PML to wait for command to complete

do
pause 1
ping PFB
handle ANY
skip
elsehandle NONE
break
endhandle
enddo
• Log in to the Admin Module at location PFB (admin)

INITIALISE
Having setup the environment at location
• Log in to the Admin Module at the HUB (if not in already)
savework
getwork
/PFB
Q LINIT
** If LINIT TRUE then PFB has Initialised
Example PML to check initialisation is complete

!loc = /PFB
do
pause 1
session comment 'Interim savework at HUB after initialisation
of PFB'
savework
getwork
break if (!loc.linit)
enddo
session comment 'Savework at HUB after confirming
initialisation of PFB'
savework
getwork
Now allocate the required DBs to the location PFB
ALLOCATE pipeapproved/master SECONDARY AT PFB
ALLOCATE pipereview/siteufa/A SECONDARY AT PFB
ALLOCATE pipeworkarea/fabwork/A PRIMARY AT PFB etc.

session comment 'Savework at HUB after allocations to PFB'

savework
Wait until all dbs have been allocated at PFB
/PFB
1
The number of members in the DBALL should match the number of DBs allocated.
Example PML to wait till all databases have been allocated

do
pause 2
session comment 'Interim savework at HUB - waiting for
allocations to PFB'
savework
getwork
!location = /PFB
q var !location.members[1].members
break if (!location.members[1].members.size() ge 28) $* no.
of allocates
enddo
session comment 'Savework at HUB after confirming allocations

to PFB'
savework
Create Teams and Databases at the Hub and User, MDB’s locally.
REPEAT FROM ****GENERATE LOCATION****, for all locations required.

Recovery from Reverse Propagation Errors
B Recovery from Reverse Propagation Errors
B.1 Background - Propagation Process

When the Global Daemon attempts to update a database with another location, it uses two
sets of data:
• The required propagation direction - always away from the Primary location of the
database
• The detailed information in the database header. This includes:
• Compaction number (Non-additive changes count) NACCNT
• Latest session number
• Claim-list changes count (CLCCNT)
• Header changes count (HCCNT, also known as ELCCNT)
The header information is compared at the two locations to determine what sort of
update is required. If the Compaction number is different, then the entire database file
must be copied, rather than just sending the required sessions. Otherwise only the
required pages in the database are sent.
If the propagation direction which is implied by the Header information at both locations
is incorrect, then the Daemon will report errors such as:
Prevented reverse propagation, should be From Remote not
Update To
Prevented reverse propagation, should be To Remote not
Copy From
The words ‘From’ and ‘To’ indicate the directions implied the Primary location, and that
inferred from the database header.
These messages are output as Errors to the daemon window as well as being recorded as
Failure in the Transaction database.
The word ‘Copy’ means that the compaction number at the secondary location is higher
than that at the primary location; the word ‘Update’ means that the latest session or
counters are higher at the secondary location than the primary location. (If neither of the
locations is the primary location, then the database at the location nearest to the primary
location is the one that is used)
A third message is also possible for another location’s system database where a file is
missing:
Missing file. Prevented reverse propagation, should be To
Remote not Copy From
© Copyright 1974 to current year. B:1 12 Series

B.2 Identifying the Problem

When the Transaction database reports that an Update has failed due to Reverse
Propagation, the following should be done for the Database element:
• Query the primary location of the database (Q PRMLOC at the DB element for the
database; or Q DB <name> contains this information)
• Query the Filename - this is useful in identifying the database in the daemon trace.
• Query the NACCNT, Latest session number, HCCNT and CLCCNT for the database
• Do the same at the remote location.
• Decide from this in which direction to RECOVER the database; and recover the
database.
• Note that the new command Q REMOTE <locname> <dbname> FILEDETAILS may be
used to gather this information for both locations.
Note: Note that the RECOVER command is the only command which is allowed to copy
the file without a check on the propagation direction.
In general, if the ‘Prevented Reverse Propagation’ message contains ‘Copy’, it is the

NACCNT attribute that is the problem. This counter is incremented by a database MERGE,
BACKTRACK (but not REVERT - the Appware uses REVERT) or Reconfiguration. In this
case, the propagation needs to copy the entire database file. However the copy has failed,
because the NACCNT is higher at the secondary location than the primary location.
The other properties are used to control normal database propagation, where only the
required sessions and the database header are sent. If the Latest session number is higher
at the secondary location than at the primary location, then database recovery is required. If
the session numbers are equal, but the HCCNT and CLCCNT attributes are higher at the
secondary location than at the primary location, then a database recovery is also required.
Usually, recovery should be made from the Primary location, unless there are good reasons
why a secondary location has the correct version of the database.
RECOVER AT <secondary location>
It may be necessary to recover the database at more than one satellite location.
If the secondary database is correct for some reason, then recovery should be from the
required secondary location:
RECOVER AT <Primary> FROM <Secondary>.
This is deliberately replacing the database at the primary location by the version at a
secondary location.
B.3 Querying Database Properties

The latest session number, and the NACCNT, HCCNT and CLCCNT attributes are
properties of the database file, and must be queried at each location. One way to do this is
to include these queries in a post-update propagation macro, which can be run from a script
specified by the EXECB attribute of the Update timer (LCOMD)
The latest session for a database may be queried by using Q SESSIONS <dbname>, for
example
Q SESSIONS MYTEAM/DESI

The database properties NACCNT, HCCNT and CLCCNT may be queried in the normal way
by navigating to the DB element for the database, for example, /*MYTEAMDESI. Attributes.
It should be emphasised that these attributes are properties of the database file, and may
differ at each location.
Alternatively, a PML object <DB> may be constructed for the database:
!DD = OBJECT DB (‘/*MYTEAM/DESI’)
Then the properties may be queried:
!DD.NACCNT
!DD.HCCNT
!DD.CLCCNT
!DD.LatestSession()
Note that the last property is a member, not a method. Primary location and filename may
also be queried:
!DD.FileName
!DD.Prmloc
The same properties may be queried for a database at a remote location ABC by using:
Q REMOTE ABC MYTEAM/DESI FILEDETAILS
Q REMOTE ABC MYTEAM/DESI LASTSESSION
The FILEDETAILS option returns the Compaction number (NACCNT), last session, Extract
list/Header changes count (HCCNT) and Claim changes count (CLCCNT) for the database
at the specified location. These may be compared with the local values.
Note: These commands return data in CSV format when used with a variable e.g.
!REMOTE ABC MYTEAM/DESI FILEDETAILS
However, the Daemon trace log does include this information if the right Trace level is
turned on. (Trace bit 3). This information is only present in the log of the location which
issued the Update. The relevant lines might read:
(6) At Tue Oct 04 01:03:24 2005 Processing DB %ABC000%/abc2315_0001
(6) At Tue Oct 04 01:03:24 2005 Compaction numbers: local 0 remote 0
(6) At Tue Oct 04 01:03:24 2005 Session numbers: local 3 remote 2
(6) At Tue Oct 04 01:03:24 2005 Claim Changes counts: local 17 remote 1
(6) At Tue Oct 04 01:03:24 2005 Extract List counts: local 3 remote 10
In this case this indicates that the current location has a more recent session than the
remote location. The Claim count only applies to a session, so its value will be ignored
unless the session numbers are the same. In this example, the implied propagation
direction is from the current location to the remote location.
However, before making the update, the Daemon checks the update direction, to make sure
that the propagation direction is consistent with the direction away from the primary location
of the database. If this check fails, then the ‘Prevented reverse propagation’ error causes
the update to fail.
Occasionally, it is not possible for the daemon to check the Update direction (Global db may
be in use). In this case, the failure will read ‘Update skipped’. This is normally a temporary
problem, and the database will be propagated as normal on the next scheduled update.

B.3.1 Automating Checks For Failure

To reduce the Administration of updates, it is possible to write a macro to collect failures and
messages from the Transaction database. This manual includes a chapter on the structure
of this database (See Transaction Audit Trail).
The structure of a Transaction command can be quite complex. This chapter contains detail
that will be useful to a macro writer.
Each command consists of a number of operations, some of which may be commands for a
remote location. Each of these in turn may also contain a set of operations and remote
commands. Operations may be dependent on the success (or failure) of earlier operations.
Some commands, such as REMOTE MERGE, or EXTRACT CLAIM are quite complex.
Others, such as scheduled updates (UPDATE ALL) are relatively simple. (See also the
Powerpoint presentation on Transactions)
Each scheduled update has an associated command element (TRINCO) which is stored
under the TIMEDUPDATES user for the date:
/2005/OCT/5/TIMEDUPDATES/ABC
where ABC is the LOCID of the location owning the Update event (LCOMD). PML Collection
syntax can be used to extract the Failures:
COLLECT ALL TRFAIL WITH (TYPE OF OWNER NEQ |TRMLST|) FOR
!DBREF
where !DBREF refers to the timed update element above.
Generally, successes (TRSUCC) and failures (TRFAIL) can be ignored when they are
owned by TRMLST, since these are progress messages. Only those in the Success list
(TRSLST) and Failure list (TRFLST) need to be considered.
Alternatively the Transactions Utility Appware could be used as a basis for a suitable macro,
since the embedded methods are extracting this information. There are two main forms
involved:
!!glbtransactions for transaction command summary
!!glbtransactionmessages
for transaction messages, failures and successes
These forms are files in %PMLLIB%\global\forms with the suffix .pmlfrm.
These forms use the Appware object GLBTRANSACTION. This contains suitable methods
using the COLLECTION object and EXPRESSON filters to collect successes and failures.
When a command is stalled, this is only reported as a Message (TRMESS) in the Message
list (TRMLST). There is no corresponding success or failure, since the command may well
complete on a re-try.
Note: Some commands (such as Claims) use Successes as a way of passing data
between operations, so contain fairly obscure data.

Using Global to Distribute Catalogue Data
C Using Global to Distribute Catalogue Data
Global can be used to distribute the catalogue databases around the world, so that projects
can include them as foreign databases.
A project cannot include a database from a Global project unless the project itself is Global
(that is, the MAKE GLOBAL command has been executed). Therefore, in order to have a
set-up where you have several projects all using a Global distributed project, they
themselves must be Global, in the MAKE GLOBAL sense: they don't have to be distributed
themselves- Single location Global projects do not require a Global licence.
Single location Global projects may be created and made Global at their resident location.
You will then be able to include the catalogue data in the usual way.
If there are many multiple-location projects that share this project, then it will be necessary
(because of your HUB licence) to create and make each project Global at the HUB and then
copy them to their eventual resident locations. You will then be able to include the catalogue
data in the usual way.
Note that if a Global project is being used to distribute catalogue databases for other
projects to include, the Overwrite DB Users flag (see admnew Files) should be disabled.
© Copyright 1974 to current year. C:1 12 Series

Using Global to Distribute Catalogue Data
© Copyright 1974 to current year. C:2 12 Series

Example Macro for Collecting and Deleting Old Commands
D Example Macro for Collecting and Deleting Old

Commands
The PML Function below allows transactions older than a specified number of days to be
deleted. This is an alternative to using Transactions Merge/Purge in Automatic Merging and
Purging of a Transaction Database. This function must be copied into PMLLIB (under
Global\functions). It may be run using !!purgeTransaction(value) where value is the number
of days to retain:
define function !!PurgeTransaction(!days is REAL)
if (!days gt 28) then
!!Alert.error('Maximum purge time is 28 days')
return
endif
if (not !!Alert.Confirm('The local daemon must be shut down before you
can continue with the purge/merge operation.
Do you wish to continue?').Boolean()) then
return
endif
$P Searching for complete transactions...
!monlengths = '31,28,31,30,31,30,31,31,30,31,30,31'
!today = object DATETIME()
!year = !today.year()
!month = !today.month()
!day = !today.date()
!hour = !today.hour()
!minute = !today.minute()
!second = !today.second()
!day = !day - !days
if (!day lt 1) then
!month = !month - 1
if (!month lt 1) then
!year = !year - 1
!month = 12
endif
if (!month eq 2) then
!leaptest = (!year - 2000) / 4
if (!leaptest eq !leaptest.int()) then
!day = 29 + !day
else
!day = 28 + !day
endif
else
!day = !monlengths.split(',')[!month].real() + !day
© Copyright 1974 to current year. D:1 12 Series

endif
endif
!date = object DATETIME(!year,!month,!day,!hour,!minute,!second)
!collection = object COLLECTION()
GOTO FRSTW TRAN
!collection.scope(!!ce)
!filter = object EXPRESSION('upc(TSTATE) eq |COMPLETE|')
!collection.filter(!filter)
!collection.type('TRINCO')
!trincos = !collection.results()
!promptstr = 'Found ' & !trincos.size().string() & ' complete transactio
ns...'
$P $!promptstr
!promptstr = 'Deleting obsolete transactions more than ' & !days.string(
& ' days old...'
$P $!promptstr
!numdel = 0
!numh = 0
do !trinco values !trincos
!datecm = object DATETIME(!trinco.datecm)
!datend = object DATETIME(!trinco.datend)
if (!trinco.incsta.upcase() eq 'PROCESSED' and !datecm.lt(!date) or !t
rinco.incsta.upcase().inset('TIMED OUT','CANCELLED','REDUNDANT') and !date
nd.lt(!date)) then
!numdel = !numdel + 1
!!CE = !trinco
DELETE TRINCO
if (!!CE.members.size() eq 0) then
DELETE TRLOC
!numh = !numh + 1
DELETE TRUSER
!numh = !numh + 1
DELETE TRDAY
!numh = !numh + 1
DELETE TRMONT
!numh = !numh + 1
DELETE TRYEAR
!numh = !numh + 1
endif
endif
endif
endif
endif
endif
enddo
$P $!numdel obsolete transactions deleted
$P $!numh associated hierarchy elements deleted
if (!numdel eq 0) then
$P No merge necessary
!!Alert.Message('No obsolete transactions found')
else

!cs = CURRENT SESSION

!locrf = !cs.locationname.dbref()
!transdbstr = 'TRANSACTION/' & !locrf.locid
!promptstr = 'Merging all sessions of transaction DB ' & !transdbstr &
'...'
$P $!promptstr
MERGE CHANGES $!transdbstr
$P Merge complete
!!Alert.Message(!numdel.string() & ' obsolete transactions deleted -
transaction database purge/merge complete')
endif
endfunction


Index
A E
ADMIN Daemon . . . . . . . . . . . . . . . . . . . 3:1 Extracts . . . . . . . . . . . . . . . . . . . . . . . . 16:1
Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:4 access . . . . . . . . . . . . . . . . . . . . . . 16:7
children . . . . . . . . . . . . . . . . . . . . . 16:1
C claim restrictions . . . . . . . . . . . . . 16:11
creating . . . . . . . . . . . . . . . . . . . . . 16:3
Command Processing . . . . . . . . . . . . . . . 2:1 creating working . . . . . . . . . . . . . . . 16:5
dropping changes . . . . . . . . . . . . 16:14
D explicit claim . . . . . . . . . . . . . . . . 16:11
extract claim . . . . . . . . . . . . . . . . . . 16:9
Database flushing . . . . . . . . . . . . . . . . . . . . 16:13
allocation check . . . . . . . . . . . . . . . . 5:1 flushing command failure . . . . . . . 16:11
allocation to location . . . . . . . . . . . . . 5:1 hierarchy . . . . . . . . . . . . . . . . . . . . 16:7
creating extract . . . . . . . . . . . . . . . . 16:3 implicit claim . . . . . . . . . . . . . . . . 16:11
creating master . . . . . . . . . . . . . . . . 16:3 issuing changes . . . . . . . . . . . . . . 16:14
de-allocation . . . . . . . . . . . . . . . 5:2, 5:3 master . . . . . . . . . . . . . . . . . . . . . . 16:1
deleting . . . . . . . . . . . . . . . . . . . . . . 11:1 merging changes . . . . . . . . . . . . . 16:16
macros . . . . . . . . . . . . . . . . . . . . . . 10:4 numbers . . . . . . . . . . . . . . . . . . . . . 16:6
manual update . . . . . . . . . . . . . . . . 10:1 parent database . . . . . . . . . . . . . . . 16:1
master of extract . . . . . . . . . . . . . . . 16:1 partial operations . . . . . . . . . . . . . 16:15
merging . . . . . . . . . . . . . . . . . . . . . . 6:1 querying family . . . . . . . . . . . . . . . . 16:2
reconfiguring . . . . . . . . . . . . . . . . . . 13:1 reference blocks . . . . . . . . . . . . . . 16:6
recovery . . . . . . . . . . . . . . . . . . . . . 12:1 refreshing . . . . . . . . . . . . . . . . . . . 16:14
recovery of global . . . . . . . . . . . . . . 12:2 releasing claims . . . . . . . . . . . . . . 16:14
recovery of primary . . . . . . . . . . . . . 12:2 sessions . . . . . . . . . . . . . . . . . . . . 16:15
recovery of primary location . . . . . . 12:2 user claim . . . . . . . . . . . . . . . . . . . 16:9
recovery of secondary . . . . . . . . . . 12:1 using in . . . . . . . . . . . . . . . . . . . . . 16:8
synchronisation . . . . . . . . . . . . . . . 10:1 variant . . . . . . . . . . . . . . . . . . . . . 16:18
update delay . . . . . . . . . . . . . . . . . . 10:2
update protection . . . . . . . . . . . . . . 10:9
F
update timing . . . . . . . . . . . . . . . . . 10:7
updating . . . . . . . . . . . . . . . . . . . . . 10:1 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . 18:1
DESIGN Manager files . . . . . . . . . . . . . 10:7
© Copyright 1974 to current year. Index page i 12 Series

G writing to . . . . . . . . . . . . . . . . . . . . . 7:1
Global Daemon
access rights . . . . . . . . . . . . . . . . . . 3:1
diagnostics . . . . . . . . . . . . . . . . . . . . 4:1
location . . . . . . . . . . . . . . . . . . . . . . . 3:1
H
Hub
changing . . . . . . . . . . . . . . . . . . . . . . 9:1
recovering . . . . . . . . . . . . . . . . . . . . . 9:2
I
ISODRAFT files . . . . . . . . . . . . . 10:7, 17:2
K
Kernel Command . . . . . . . . . . . . . . 2:1, 7:1
L
Locations
off-line . . . . . . . . . . . . . . . . . . . . . . . 17:1
M
Macros . . . . . . . . . . . . . . . . . . . . . . . . . 10:4
P
Pending file . . . . . . . . . . . . . . . . . . . 2:1, 8:1
PLOT files . . . . . . . . . . . . . . . . . . 10:7, 17:2
Projects
backing up . . . . . . . . . . . . . . . . . . . 15:1
T
Transaction Audit . . . . . . . . . . . . . . . . . . 7:1
Transaction database
audit trail cancelled commands . . . . 7:7
audit trail dates and counts . . . . . . . 7:5
audit trail from TRINCO . . . . . . . . . . 7:2
audit trail from TROPER . . . . . . . . . . 7:4
audit trail from TROUCO . . . . . . . . . 7:3
audit trail results and messages . . . . 7:7
commands . . . . . . . . . . . . . . . . 2:1, 7:1
management . . . . . . . . . . . . . . . . . 12:3
merging . . . . . . . . . . . . . . . . . . . . . 12:3
merging and purging . . . . . . . . . . . 7:13
reading from . . . . . . . . . . . . . . . . . . . 7:1
reconfiguring . . . . . . . . . . . . . . . . . . 12:4
renewing . . . . . . . . . . . . . . . . . . . . . 12:3
© Copyright 1974 to current year. Index page ii 12 Series


PDGRGP PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

PDGRGP PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Running Global Projects

AVEVA Solutions Limited

Date Version Comments / Remarks

Running Global Projects

Running Global Projects

Daemon Diagnostics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1

Database Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:1

Merging Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1

© Copyright 1974 to current year. i 12 Series

Procedure for Merging Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:2

Transaction Audit Trail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1

Pending File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:1

Updates and Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:1

© Copyright 1974 to current year. ii 12 Series

Update Timings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:7

Deleting Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11:1

Recommendations for Reconfiguring (User dBs) . . . . . . . . . . . . . 13:1

© Copyright 1974 to current year. iii 12 Series

Extract Flush Commands Failing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:11

Off-line Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17:1

Firewall Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18:1

Suggested Housekeeping Guidelines for Projects . . . . . . . . . . . . 19:1

© Copyright 1974 to current year. iv 12 Series

Locating and Closing Locked and/or Open Database Files . . . . . . . . . . . . . . . . . . . . . . . . 19:8

Project Setup Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A:1

Using Global to Distribute Catalogue Data. . . . . . . . . . . . . . . . . . . .C:1

© Copyright 1974 to current year. v 12 Series

© Copyright 1974 to current year. vi 12 Series

Note: References to 'Windows' in this document mean MS Windows 2000 or MS Windows

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

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

2 Global Mode of Operation

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

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

3.1 Location of the Daemon

3.2 Daemon Access Rights

3.3 Daemon Buffer Size

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

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

The Global daemon has the following types of diagnostic output:

4 = Remote Procedure Calls

64 = Event Loop Thread

128 = Operation Thread

256 = Trans DB I/O

512 = Not used

1024 = Not used

2048 = Dabacon Detail

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

4.2.1 Diagnostic Level

16 = Dabacon thread summary

32 = Dabacon thread detail

64 = Propagation thread summary

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

128 = Propagation thread detail

255 = Full logging.

Alternatively, log values can be selected by clicking the Define button.

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

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

5.1 Allocating Databases to Locations

If a de-allocation is in progress (see the DEALLOCATION command), then the allocation

5.2 Checking Database Allocations

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

/Satellite - Navigate to the location (LOC element)