Running Global Projects

8/13/2019 Running Global Projects

1/120

Running Global Projects


2/120

Disclaimer

Information of a technical nature, and particulars of the product and its use, is given by AVEVASolutions Ltd and its subsidiaries without warranty. AVEVA Solutions Ltd and its subsidiaries disclaim

any and all warranties and conditions, expressed or implied, to the fullest extent permitted by law.

Neither the author nor AVEVA Solutions Ltd, or any of its subsidiaries, shall be liable to any person orentity for any actions, claims, loss or damage arising from the use or possession of any information,particulars, or errors in this publication, or any incorrect use of the product, whatsoever.

Copyright

Copyright and all other intellectual property rights in this manual and the associated software, and everypart of it (including source code, object code, any data contained in it, the manual and any otherdocumentation supplied with it) belongs to AVEVA Solutions Ltd or its subsidiaries.

All other rights are reserved to AVEVA Solutions Ltd and its subsidiaries. The information contained in

this document is commercially sensitive, and shall not be copied, reproduced, stored in a retrievalsystem, or transmitted without the prior written permission of AVEVA Solutions Ltd Where suchpermission is granted, it expressly requires that this Disclaimer and Copyright notice is prominentlydisplayed at the beginning of every copy that is made.

The manual and associated documentation may not be adapted, reproduced, or copied, in any materialor electronic form, without the prior written permission of AVEVA Solutions Ltd. The user may also notreverse engineer, decompile, copy, or adapt the associated software. Neither the whole, nor part of theproduct described in this publication may be incorporated into any third-party software, product,machine, or system without the prior written permission of AVEVA Solutions Ltd, save as permitted bylaw. Any such unauthorised action is strictly prohibited, and may give rise to civil liabilities and criminalprosecution.

The AVEVA products described in this guide are to be installed and operated strictly in accordance withthe terms and conditions of the respective license agreements, and in accordance with the relevantUser Documentation. Unauthorised or unlicensed use of the product is strictly prohibited.

First published September 2007

AVEVA Solutions Ltd, and its subsidiaries

AVEVA Solutions Ltd, High Cross, Madingley Road, Cambridge, CB3 0HB, United Kingdom

Trademarks

AVEVA and Tribon are registered trademarks of AVEVA Solutions Ltd or its subsidiaries. Unauthorised

use of the AVEVA or Tribon trademarks is strictly forbidden.

AVEVA product names are trademarks or registered trademarks of AVEVA Solutions Ltd or itssubsidiaries, registered in the UK, Europe and other countries (worldwide).

The copyright, trade mark rights, or other intellectual property rights in any other product, its name orlogo belongs to its respective owner.

AVEVA Solut ions Ltd


3/120


Contents Page

12.0i



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 Diagnost ics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1

Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1

Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:2

Diagnostic Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:2

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

Al locat ing Databases to Locat ions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

Remote Merging on Non-Extract Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1


4/120

12.0ii


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

Merging Extract Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:2

Transaction Audi t 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 Audi t Trail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:2

As seen from the TRINCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:2

As seen from the TROUCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:3

As seen from the TROPER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:4

Audi t Trai l Dates and Counts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:5

Cancelled Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:7

Processing of Results and Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:7

Transact ion Success and Failure Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:8

Scheduled Updates - Successes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:8

Scheduled Update - Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:9

Failed File Copies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:11

Reasons Other ADMIN Commands Can Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:12

Automat ic Merging and Purg ing of a Transact ion 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 Picture and other Drawing-fi les . . . . . . . . . . . . . . . . . . . . . . . . 10:2

Propagation of Final Designer, Schematics and Marine Hull Drawing Files . 10:3

Propagation of Inter-Database Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:4

Update Timings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:4


5/120

12.0


ii i

Transfer of Other Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:5

Reverse Propagation Prevent ion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:7

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:6Reference Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:7

Setting up an Extract Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:7

Using DACs with Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:8

Using Extracts in DESIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:8

Managing Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:9

User Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:9

Extract Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:9

Command Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:10


6/120

12.0iv


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

Relationship between Extract and User Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:11

How to Find Out What You Can Claim. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:11Flushing Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:13

Releasing Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:14

Issuing Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:14

Dropping Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:14

Refreshing an Extract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:14

Partial Operat ions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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:2

Change Primary to Off line location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17:2

Change Primary from Offl ine location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17:3

Deallocation from Off line location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17:3

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

Limiting Ports Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18:1

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

Introduct ion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:1

Dice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:1

Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:3

Update Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:3Timing 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


7/120

12.0


v

Database File Locks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:8

Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:8

Avoiding Random File locks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:8Locating and Closing Locked and/or Open Database Files . . . . . . . . . . . . . . . . . . . . . . . . 19:8

Distributed Extract Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:10

Project Administ ration Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:10

ADMIN Lead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:11

Discipline SMEs (Subject Matter Experts) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:11

Global Satellite Co-ordinator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:11

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

Recovery f rom Reverse Propagation Errors . . . . . . . . . . . . . . . . . .B:1

Background - Propagation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B:1

Identi fying the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B:2

Querying Database Propert ies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B:2

Automating Checks For Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B:4

Using Global to Dist ribute Catalogue Data. . . . . . . . . . . . . . . . . . . .C:1

Example Macro for Collecting and Deleting Old Commands . . . . .D:1


8/120

12.0vi



9/120


Introduction

12.01:1

1 Introduction

This document proposes a set of guidelines for the effective use of the AVEVA Globalproduct. The guidelines result from current working experience and may be amended in thelight of future experience. Global manages a project distributed over several differentgeographical locations connected by a Wide Area Network (for example the Internet) and so

presents special situations for the administrator and engineering user, which the guidelinesaddress.

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

AVEVA Global can be used to enhance projects created in either the AVEVA Plant orAVEVA Marine group of products - henceforth known as the base product in thisdocument.


10/120

12.01:2


Introduction


11/120


Global Mode of Operation

12.02:1

2 Global Mode of Operation

In standard projects, commands are processed one at a time so that the nextcommandcannot begin until the previous one has finished. In principle, the state of the system istherefore always known. In Global, remote commands are processed in paralleland so thenext 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 workin 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 transactiondatabaseat 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 meansthat commands are guaranteed to complete, but some commands may not succeed. Somemay roll back, while others may just fail.

For further information about the transaction database, see Transaction Audit Trail, andTransaction Database Management.


12/120

12.02:2


Global Mode of Operation


13/120


Global Daemon

12.03:1

3 Global Daemon

The Global daemon (sometimes referred to as the ADMIN daemon) is supplied with theGlobal product, in the default install folder. It uses RPC, which is part of the standardWindows software, and so no additional software has to be installed.

There must be one Global daemon running for each Project at a Location.Installing the Global daemon is described in theGlobal Installation Guide,configuring andstarting the daemon is described in the Global User Guide.

3.1 Location of the Daemon

We recommend that the daemon is run on the file server, thus reducing the risk of it beingaccidentally 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 persistafter a user logs out; and to start automatically when a machine is restarted. When thedaemon 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 daemonmust have sufficient access rights to all project databases at the current location. Forexample, a daemon running at Location A will need to have Read/Write access to all of thedatabases at Location A.

3.3 Daemon Buffer Size

Dabacon buffer size can be set in the GLOBALDAEMON module definition. The defaultvalue is 2560000 but the Administrator may specify a larger or smaller value than this. Notethat the buffer size should be at least this value in projects where distributed Extracts arebeing used.

The Dabacon buffer size can be changed by using the MODULE command. See theAdministrator Command Reference Manualfor details.


14/120

12.03:2


Global Daemon


15/120


Daemon Diagnostics

12.04:1

4 Daemon Diagnostics

The Global daemon has the following types of diagnostic output:

Tracing.

Logging.

4.1 Tracing

Tracing can be switched on when you start the daemon. If you are running the Globaldaemon as a service, add a line to the startup batch file singleds.bat to set the environmentvariable DEBUG_ADMIND as follows:

DEBUG_ADMI ND=1023

If you are not using the Global daemon as a service, you can set DEBUG_ADMIND from thecommand line.

The value of the DEBUG_ADMIND variable determines the type of activities that are traced:

These values are bit settings, so if you want to trace a combination of activities, you add theabove values together. For example, to trace Systems DB access and the Event Loop

thread only, you would set DEBUG_ADMIND as follows:

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


16/120

12.04:2


Daemon Diagnostics

DEBUG_ADMI ND=80

To enable tracing for all activities, you would set the DEBUG_ADMIND value to 3071. Auseful level of tracing for tracking commands is 896.

Full tracing can be verbose and fill disk space rapidly, the recommended value of 896 allowsthe administrator to gain an idea of the current number of commands running through thesystem.

This may help when bringing down a daemon at a particular location. Further tracing may berequired when investigating a particular problem.

4.2 Logging

It is beneficial to have the Daemon log setting activated for troubleshooting purposes as wellas 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 willdisplay the Local Daemon Settings form. In the appropriate text boxes, enter theDiagnostic Logfile name, the Diagnostic Level (see below), and finally Enable theDiagnostic Loggingusing the drop-down list. (Note: If you use an environment variable inthe log file path, it must be defined in the daemon script or in the window from which youstarted the daemon.)

4.2.1 Diagnostic Level

The number to be entered is the sum of the code numbers for the individual requirementsshown 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


17/120


Daemon Diagnostics

12.04:3

Alternatively, log values can be selected by clicking the Definebutton.

The log files can be sent to the administering location at regular intervals.

The log file will get bigger over time. If you want to keep the log record, but 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 themoved log file until it checks the log file location and finds it has moved, and then a new logfile will be generated.

Note: Logging does not capture the same data as tracing, for full debugging purposes thetrace facility provides much more comprehensive internal diagnostics.

128 = Propagation thread detail

255 = Full logging.

0 = None


18/120

12.04:4


Daemon Diagnostics


19/120


Database Allocation

12.05:1

5 Database Allocation

5.1 Allocat ing Databases to Locations

Before allocating databases, ensure that both daemons are running by selectingQuery>GlobalStates>Communications or by issuing a Ping command.

ALLOCATEcommands can be given in sequence without waiting for the first allocate tofinish. However, the same Allocate command should not be done twice, unless you are surethat the allocation has failed and that there is no entry in the transaction databases at eitherof the locations affected by the allocation.

When databases have been allocated to a location, you cannot add databases to MDBsuntil all allocations have been completed, so it is advisable to check the progress ofallocations first.

It is advisable to use macro input for long lists of database allocations; for example:

ALLOCATE PRI MARY at / Satel l i t e

ALLOCATE at / Sat el l i t eand 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 arecomplete, whether the command has been executed through the GUI, or as amanual command. This is described in the next section.

If a de-allocation is in progress (see the DEALLOCATIONcommand), then the allocationwill stall until the de-allocation is complete before commencing.

5.2 Checking Database Allocat ions

Once you have finished database allocation, you must check that the commands have beencompleted. You can do this by selecting DB & Extracts from the Admin Elements form,which displays a list of all the allocated databases at the location where dBs are beingallocated. Alternatively, you can check that the allocation has completed successfully fromthe 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 arephysically 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 Satelliteand/or if database sizes are large.


20/120

12.05:2


Database Allocation

A Get Work must be done prior to listing the DBALL, (that is, you must carry on doing a GetWork to see when the databases have been allocated). Allocation is successful when theDBALL list contains all of the databases allocated.

getwork

5.3 De-al locat ing 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 locationby the hub while it is being read, then the database(s) de-allocated will not immediately bedeleted from the satellite locations.

The command will be stalled in the transaction database and, once all users at the locationexit 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 you change a database from primary tosecondary while a user is reading/writing to it, the user will be able to write to thedatabase until such a time as that user changes modules. A dB does not need to beprimary at the HUB, just as long as it is not primary at the location where it is being

de-allocated.

/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


21/120


Database Allocation

12.05:3

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 mayoccur:

Whenever a database is allocated to a location. The database is copied from the hub tothe new location by the Global daemon. As the file is copied over the networkconnection, a file named

prjnnnn.admnew

is created. Once copying is complete, this file is renamed automatically to

prjnnn


22/120

12.05:4


Database Allocation

For example: abc0001.admnew is created while copying, and it is renamed toabc0001once 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 deletethem, except in extreme cases. If the daemon is running continuously and a Copy dBoperation fails then the system should tidy up. Normally .admnew files are retained forlater use. However, if the daemon dies (such as in a power-cut) during the process thismay result in an invalid .admnew file. In this case the file should be removed from theoperating 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 containsthe 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 whichdoes not include the database. Once all such users have exited, the copy will normallysucceed.

If the database is locked by a Dead user - a session for a user which has beenexpunged. In this case Global attempts to rename the .admnew file, but it fails.

To resolve the second situation, you must do one of the following: either

Ensure that the sessions for all dead users have been killed. Also ensure that noforeign projects are reading this database; or

Use the NET FILE command in a cmd window (or a suitable third party tool) to identifynetwork access to the file, and close it.

If the project is not used as a foreign project, there is an additional alternative. TheOverwrite 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 andthere are no database READERS in the project, then Global will overwrite the lockedfile 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 theGlobal project.

Overwriting of locked databases may be enabled by using the MODIFY dialogue for thelocation on the Admin Elements form to enable Overwriting, or by setting the Overwrite DBUsers flag (LCPOVW) to 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 environmentvariables must be set before starting the daemon. If the daemon is run as a service then theenvironment variables must be set within the kick-off batch script.


23/120


Merging Databases

12.06:1

6 Merging Databases

When setting up a project in a Global environment, you are likely to create many sessions inthe Global database. This is because when ADMIN issues a Daemon command, it first doesa SAVEWORK to give the Daemon an up-to-date view of the Global database. The Daemonalso may add sessions to the Global database.

We recommend that you should merge changes for the Global database and possibly thesystem database after setting up a Global project. This should also be done after makingsignificant changes to the project setup.

6.1 Remote Merging on Non-Extract Databases

Take care when merging project databases. Databases can only be merged at their primarylocations. It is important to note that when a project database is merged, the databasesession will effectively be lost. Thus the ability for Global to send only session changes islost too.

It is therefore recommended that you use the REMOTE MERGE command (or selectRemote> Remote Change Management> Merge Changes from the ADMIN menu bar) tosynchronise 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, you cannot merge the database.

REMOTE MERGEmerges the database at secondary locations after it has been merged atthe primary location in order to prevent unnecessary copying of the entire database when itis next updated.

You are advised to stop scheduled updates and avoid adhoc updates when using REMOTEMERGE. If scheduled updates are left in place, then unnecessary copying of entiredatabases 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 primarylocation would be lost.

Note that database extracts which own other extracts cannot be merged using REMOTEMERGE. See Merging Extract Databases.


24/120

12.06:2


Merging Databases

6.1.1 Procedure for Merging Changes

6.2 Merging Extract DatabasesThe REMOTE MERGE command cannot be used on extract databases if they own otherextracts. Instead, ADMIN must be used to merge these. The extract to be merged and all itsimmediate children must be primary at the same location. This is because the childextracts contain references to sessions in the owning extract.

Procedure to merge an individual extract database:

Select a suitable time to execute the merge, and ensure that all users have left theproject

Use CHANGE PRIMARY to bring all its immediate child extracts to the primary locationof the extract being merged

MERGE the database


25/120


Merging Databases

12.06:3

Use CHANGE PRIMARY to return the child extracts back to their original primarylocation.

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 PRIMARYcommands). 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 projectHub. However if an extract database owns working extracts, it must be merged at itsoriginal primary location, since the working extract files only exist at that location.


26/120

12.06:4


Merging Databases


27/120


Transaction Audit Trail

12.07:1

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 thepending file until complete.

The transaction database can be navigated using the command line in ADMIN usingstandard navigation commands. The information in the database will give the systemadministrator more information about the progress of commands, and details of whycommands have failed. Much of this information is available through the user interface butthis section is included to instruct the system administrator on how to interpret thetransaction 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 toperform actions that a user at a particular site wishes to effect: for example to allocatedatabases (from ADMIN), or to claim elements (say from DESIGN).

7.1 Writing to the Database

The Daemon writes a persisted copy of each input command to the database as soon as itis received, and each operation and output command is written as soon as all have beensuccessfully created at both the create operations and create post operations stage.

State changes for input and output commands, and operations are written immediately afterthe state change. However optimisation may reduce the number of changes that areactually committed to the database.

All results from an operation are written after the operation completes, and from an outputcommand as soon as they have been received from the location to which it was sent andwhich 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 f rom the Database

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

7.2.1 Program In it ial isat ion

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


28/120

12.07:2



progressing these commands. Only unfinished commands will be read. All others will beignored and not validated for errors.

If there are any errors found in reading the database, the daemon will not start. It will then benecessary to provide a (probably) empty database so that the daemon will start from freshand 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 usedby 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 localadministration information such as element claims. However, these commands aretotally ignored by the daemon.

7.3 Following the Audit Trail

The following section refers to elements within the Transaction Database. For more detailabout Transaction Database Elements refer to the Administrator Command ReferenceManual.

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 outputcommand (TROUCO) that sent the command. If this is from another location it is anunknown reference as it is in another transaction database that is not in the current MDBand 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 towhich it is eventually heading is DESLOC. Normally, commands are passed from location tolocation 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 topass on some other commands. It is not obvious which commands are exceptions to thenormal rule.

If INCSTA = Acknowledged then an acknowledgement has gone to the sender of thecommand. 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 operationssuccessfully 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


29/120



12.07:3

failure can terminate the TRINCO. Its TRPASS will be set to FALSE, its state will beComplete or a later state, and it may own a TRMLST/TRMESS and perhaps a TRFAIL butno 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 haspassed. This stay of execution will persist until EXTIME has expired, even if this is a longerperiod than the Time out.

The TRINCO stays in Ready state for as long as all its operation and output commandstake to complete. Once the TRINCO has been set to ready the command cannot time outuntil all operations have also timed out.

When all member operations and output commands have completed INCSTA is set toComplete. All failures and successes generated by them are collected together andhanded on to the sending TROUCO (which stores them). The success state of thecommand (TRPASS) is set to true if all operations have succeeded. INCSTA is now atReplied.

Once a reply acknowledgement has been received back from the previous location, INCSTAis set to Processed and no more actions will take place.

There are other terminating conditions of a TRINCO; Timed Out means that the commanddid not manage to start before either its end time was reached, or the number of retriesallowed 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 tookplace. Owned TROUCOs and TROPERs may be set to cancelled if they have not yetstarted 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 andpossibly again when post operations are generated. These TROUCOs have ORILOC set tothe current site, DESLOC the ultimate processing destination of the command and are sentto 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 iscreated 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 TROUCOis a duplicate of the owning TRINCO and when it is passed on its ORILOC is that of itsowning TRINCO.

TROUCOs store the progress of the communication of the command with the location towhich it is sent (NXTARL) and the reply.

OUTSTA is the state of processing of a TROUCO. Its value is Waiting until the command isready for processing. This may be delayed because of dependency on other operations oroutput commands. These dependencies are stored in DEPCOU, DEPEND and DEPTYPattributes - the number of dependencies, the elements depended on, and whether it is onsuccess or failure.

When all previous commands and operations on which the TROUCO is dependent havecompleted, and when the condition of the dependencies are met the TROUCOs statechanges to Ready. After this point the command is sent to its target location and its state isset to Sent. If the sending fails the TROUCO is Stalled and remains so until the timebetween 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


30/120

12.07:4



has been created to store the command. This is stored in the TROUCOs CMREF attribute.For remote locations this will usually be an unknown reference since the specific transactiondatabase 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 underTRFLST and TRSLST elements and the TRPASS attribute and OUTSTA goes toProcessed.

TROUCOs can terminate by timing out if they fail to send in the lifetime prescribed (TimedOut. They may never be sent if dependencies are not met, in which case they terminate asRedundant.

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 isused 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 usersand locations, and between locations. Extra commands may be generated, but in the end itis 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 prioroperation or command and can be executed. It then goes to Ready and put into a listready 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 Completeand 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 thiscase the OPSTAT is set to Stalled and will be reset back to Ready after time WAITIM. Thenumber of retries after stalling is stored in NRETRY. Operations will time out if still stalled atdate ENDTIM or the number of retries exceeds MAXTRY. In this case OPSTAT goes toComplete and finally TimedOut.

When an operation is complete it may need to generate extra operations and commands theform of which are dependent on the results of the operation. If this create operation is stalledthen the operation goes to OPSTAT Stalled Post Operation and will go back to Completeafter WAITIM. When post operations are successfully created, or none are needed, then theoperation 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 terminatein state Redundant. This may happen if a command is cancelled.


31/120



12.07:5

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 givesinformation 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 isreached so that it records, for example, the date when a command was last sent, oracknowledge.

The states that set associated dates and counts are:


32/120

12.07:6



TRINCO:

TROUCO:

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 EXTIMEhas 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 createdCANCELLED DATEND Date command cancelled by user

PROCESSED DATEND Date all processing of command finishedincluding reply acknowledgement ofcommand received

NREPAK Number of times reply acknowledgementreceived

WAIT DATECR Date command created by owning TRINCOor previous TROPER or TROUCO

READY DATERD Date command made ready to be sent whendependencies 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 replyacknowledgement 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.


33/120



12.07:7

TROPER:

7.5 Cancelled Commands

Commands can be cancelled at the location where they were first input. There are rules asto what a particular user may cancel, but this section describes what happens in thedaemon once a cancel command has been passed to it.

Cancellation only applies to TRINCOs and not to any particular operation it has. Thecancellation is immediately effected if the TRINCO has INCSTA of state Waiting orStalled.

If the TRINCO is Ready then all of its operations and output commands are inspected. Ifthese TROPERs and TROUCOs are all Waiting, Ready or Stalled then those in Readyor Stalled state are set to cancelled and the waiting ones become Redundant. And theTRINCO 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, orrejected.

7.6 Processing of Results and Messages

When operations execute they may generate successes and failures. These are bufferedand written to the transaction database as TRSUCC and TRFAIL elements when theoperations becomes Complete. Specific messages may also be generated. Messages areautomatically generated for each success and failure, each time an operation or outputcommand stalls.

Input Commands can have messages. These are automatically generated if the createoperations stage stall and if a cancel is attempted. There may also be failures andsuccesses but these are rarely generated.

WAIT DATECR Date operation created by owning TRINCO or

previous TROPER or TROUCO

READY DATERD Date operation set ready when all dependenciessatisfied,

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 TRINCOREDUNDANT DATEND Date operation discovered to be redundant

PROCESSED DATEND Date all processing of operation finished - includingpost operations generated.


34/120

12.07:8



Messages are not stored in the database except under the TRINCO that was originallyreceived from a user (not another locations TROUCO) and under the TROPERs andTROUCOs 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 theTRINCOs originating TROUCO. If the sender was the user then the messages are stored inthe database for review under the relevant element: In particular when these messages arepassed between sites the TROUCO receives a set of messages each of which may havebeen generated by different operations, and yet they will now all belong to the singleTROUCO. The messages contain sufficient attribute information to indicate the location thatthe message originated from, the operation type etc.

When the messages are finally stored below the originating command successes andfailures are persisted as TRSUCC and TRFAIL elements under a TRMLST element. Thiswill distinguish them from the result successes and fails that are persisted when theoperation 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 bereported for database file copies. The sections below give several examples of what youcan 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:


35/120



12.07:9

In this case, all successful database updates report no data to send since the databasewas 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 anUpdate. 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 arealways 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 andthen 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 thesuccess for each database as well as cumulated in the update summary. In the case ofcopies, the number of pages sent will only be reported if the copy is executed locally. ForDRAFT databases, the number of picture-files sent is also reported.

The update summary also reports on the number of other data files transferred (see alsosuccess for Exchange of other data). Note that this will always report a success even ifthere 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


36/120

12.07:10



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 remotemerge is executed without stopping scheduled updates. Normally it will be necessary torecover the database to resolve this error.

Prevention of Reverse propagation may also be reported in the following situation - asatellite has executed a direct update (UPDATE DIRECT from the command-line) with anon-neighbour satellite. The next scheduled update with the intermediate location will reportPrevented reverse propagation. In this case, scheduled updates will eventually resolve thesituation.

The following table summarises Failure messages that can be generated for Scheduledupdates. This does not include all possible failures that may be generated from failed filecopies.

Error No Symptom Reason

- Scheduled update was suppressed Attribute LNOUPD set TRUE onLCOMD to disable scheduledupdate

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

- Update will not report results to CAM this failure cannot be reported atCAM - usually due to locationunavailable

612 Prevented reverse copying Secondary location has a higher

compaction number than theprimary location. Database mayneed recovering

611 Prevented reverse update Secondary location has a higher session number than the primarylocation. Database may needrecovering

613 Unable to check update direction -update skipped

The Global database is in use. Thisis normally temporary, due toanother command.


37/120



12.07:11

7.7.3 Failed File Copies

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

610 Update skipped - cannot get localdetails for

The specified database is in use atthe current location. This is normallytemporary, due to another command

using the database.

610 Update skipped - cannot get remotedetails for

The specified database is in use atthe remote location. This is normallytemporary.

610 Update skipped - cannot get local/remote details for CAM system DB

In the case of system databases, ifone system db is in use, then theupdate will fail for any system db(they all have the same DB number)

- Failed database copy - file may be inuse at HUB

Unspecified COPY failure -compaction numbers are still out of

step. If the copy destination was theupdate location, then additionalfailures will give further detail.

619 Cannot verify success - may befailed COPY

Unspecified COPY failure -compaction numbers are still out ofstep. No further detail is available.

- Missing remote/local file. Preventedreverse propagation.

System databases only. A systemdatabase file is missing at thespecified location. This may need tobe recovered.

615 Update failure - possibly database

error

A database error was encountered

during the update. Full detail will bein the daemon log

614 Update failure - database pages arenot contiguous

The database file is corrupt at thedestination. This database must berecovered from its primary location.

628 Failed database copy. File in use.Cannot remove

Database file is locked andoverwriting is disabled. File copyhas failed to commit the .admnewfile. The .admnew file will beretained for later use.

630 Failed database copy - update forprevious extract failed

Prevention of an inconsistent extracthierarchy. A file copy for an extractdb has not been attempted becauseof an update failure on anotherextract of the same database. (Notfully working at Global2.4)


38/120

12.07:12



In this example, the database still had readers, so the copy could not be completed. Anadditional failure reports that 18 pages have been copied from the remote location. The nextretry validates the .admnew file, but still cannot commit it due to readers. A further retryvalidates the .admnew file again and attempts to commit it. In this case there are noreaders, but the file is locked.

In this case, the SYNCHRONISE command eventually succeeded, since Overwriting wasenabled. 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 copyfailed.

Detailed failures for file copies can only be reported at the destination. During a scheduledupdate, the success of a copy is verified by checking that the compaction number haschanged. 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 you will use for project administration include operations thatchange the Global database. These operations fail if they cannot claim the appropriateelement, 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


39/120



12.07:13

Refer to Extract Flush Commands Failingand Reasons Claims and Flushes can Failfor nonAdmin 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 howlong successful commands and/or failed commands can remain in the transactiondatabase. At regular intervals, set by the administrator, the system deletes the expiredcommands, merges the database to a new file, deletes the existing file and then copies themerged file to the original filename.

As with all databases, the merging of a transaction database can be carried out only whenno other users are currently accessing it.

The procedure for initiating automatic merging and purging and setting the rules is in theGlobalUser Guide.

The Global User Guide also contains information on manually merging and purgingdatabases.

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

Action Cause of Failure


40/120

12.07:14




41/120


Pending File

12.08:1

8 Pending File

On a Global network, most remote commands that are stalled for any reason at a locationare placed in the transaction database at that location, for later processing, (see nextchapter).

A small number of commands that cannot be carried out at once, known as kernelcommands, are instead stored in a locations pending file for later processing. There arevarious 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 Satellites transaction database:

ALLOCATE (PRIMARY) CHANGE PRIMARY

All other commands use the transaction database to achieve a similar effect (see nextchapter).

Once a pending file has been created at a location, it will continue to exist. When the kernelcommands stored in it have been executed, they will be deleted from the file. You can tell ifthere are any outstanding commands by the size of the file: if it is empty, it will be zero size.You can read the contents of the pending file 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.exeutility provided in the Global install folder.For example, if the pending file is C:\AVEVA\projects\abc000\pending, the command to read

it is:i nst al l pat h\ gl bpend. exe C: \ AVEVA\ pr oj ect s\ abc000\ pendi ng

You will be able to read the pending commands from the output.


42/120

12.08:2


Pending File


43/120


Changing the Hub

12.09:1

9 Changing the Hub

9.1 Preparat ion for Changing the Hub

Changing the Hub is a straightforward process, but any break in communication links couldpotentially complicate matters. Global can handle and recover from communication failure,

but we recommend that you take the following preliminary steps to minimise the risk of Hubchange failure:

Ensure that the daemon is running at both the current Hub and the Satellite which willbecome the new hub. This can be done by selecting Query>GlobalStates>Communications from the ADMIN, DRAFT, DESIGN, DIAGRAMS orSPOOLER module or by issuing a Ping command.

Ensure that you have the project at the Hub backed up and that at least the Globaldatabase (i.e. prjglb) at the satellites is backed up.

Once these steps have been taken, you can change the Hub through the commandline. The GUI will automatically change at the old Hub. At the new Hub, re-enterADMIN.

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 theproposed new Hub, for example /Tokyo, before changing the Hub. This may be doneusing the command:

Allocate all at /Tokyo override propg

or by checking the option Al locate all to allocate non-propagating databases on theDatabase Allocation (by location) form.

You should make sure that the change of Hub location is complete before working witheither the new or old Hub. Check the following attribute to confirm that the hub change hasbeen successful. For example, if you are changing the Hub from London to Tokyo, thennavigate 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.

You will also see that the location parent attribute of each location (locrf) has changed. Thisis 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 l ocr f

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


44/120

12.09:2


Changing the Hub

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

/ Tokyo

q l ocr f If the Locrf of Tokyo is set to Nulref, then the hub change has been successful. The newhub, Tokyo, has no parent location.

9.2 Recovering from Change Hub Fai lure

Very rarely, the project may be in a state where a Hub change has been carried out but hasfailed. In this situation, you may effectively have no Hub.

During a Hub change, or when a Hub change has failed, the identities of the old and newhubs are recorded on the Location World /*GL. Navigate to the location world and queryHubrf, Prvrf and Nxthb attributes:

/ *GLq hubrf

q pr vr f

q nxt hb

When there is no Hub, then Prvrf records the name of the previous hub and Nxthb recordsthe name of the next hub. The Hubrf attribute is set to Nulref. During a Hub change fromLondon 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 partof the failure operations of the Hub change. You should check progress of the command inthe transaction database. If this recovery fails, then the System Administrator must recoverthe 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 recoveryoperation, since this prevents incompatible changes being made by two competingusers at different locations.

To force recovery from a failed Hub change, at the original Hub, use theData>Recover>Hub Locationoption from the ADMIN menu bar, or type the followingcommand:

PREVOWNER HUB

Re-enter the ADMIN module. This will restore the Hub location and the Hub GUI. (Note: ifdaemons are running, then the original Hub location command may still be in progress andwill attempt to commit the hub change or recover the original hub as appropriate)

Make sure that the PREVOWNERcommand is complete before working with either the newor old Hub, as otherwise it is possible to end up with twoHubs. If this happens, the Globaldatabase must be propagated (or physically copied) from the new Hub to the old beforefurther administration is be carried out. If the new Hub was to merge changes while the oldHub was still active, the system would not be able to recover. It would be necessary toreinstate the Global database from the backup taken before the change of Hub location wasundertaken.


45/120


Updates and Synchronisation

12.010:1

10 Updates and Synchronisat ion

Within Global there is the functionality to update databases automatically or manually.Additionally, we can manually synchronise databases.

10.1 SynchronisationSynchronisation can be carried out at both Hub and Satellite locations. This process can beused to synchronise databases at one location with the corresponding databases at adifferent 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 sentand 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 attemptto synchronise the database at the two locations as follows:

If the sending location is the primary location, it will update the database at eachlocation along the network path to the destination;

If the receiving location is the primary location, it will execute a SYNCHRONISEcommand to request an update from the primary location

If the primary location lies between the two locations, then it will synchronise thedatabase at the sending location with the primary location and update the databasefrom 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 inReverse propagation errors from scheduled updates. This happens because UPDATEDIRECT results in the database being more recent at the secondary destination of theupdate than at the intermediate satellite through which scheduled updates are routed.


46/120

12.010:2



To learn more about Reverse Propagation errors, see Recovery from Reverse PropagationErrors.

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 sixtimes before the System databases and the update information are re-read. Thus, we havethe 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.4 Propagation of Picture and other Drawing-files

Picture, Schematics and Neutral Format files are propagated the same time that a Databaseis propagated. If the Daemon finds that a Database has been modified at its primary locationit will query the Picture directory (referenced by variable %ABCPIC% in the case of a PADDdatabase), and the Neutral Format directory (referenced by variable %ABCDIA% in thecase of a SCHE database) at both locations to work out any changes. New and missing fileswill be copied from the Primary Location to all Secondary Locations, any old files will bedeleted.

If the Database is found to be the same at both locations, then it is considered not to requirePropagation, 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 ispossible to enable the Propagation of these files by ticking the check box on the Modify/Create dB form, as below. This will allow Picture and Neutral Format files to be propagatedto any other location.


47/120



12.010:3

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 environmentvariables %ABCPIC% and %ABCDIA% must be set in the Daemon kick-off script.

Final Designer, Schematics and Marine Drawings files are always propagated, even ifPicture/Neutral Format File Propagation is disabled.

10.5 Propagation of Final Designer, Schematics and

Marine Hull Drawing Files

Final Designer, Schematics and Marine Hull Drawing files differ from Picture and NeutralFormat Files because they are always propagated regardless as to whether the PropagatePicture/Neutral Format Files check box is unchecked or not. The reason for this is that,unlike picture files, they cannot be regenerated at a secondary location.


48/120

12.010:4



For these files to be successfully propagated the following environment variable must be setin the Daemon kick-off script:

The {ABC} DIA folder can contain Neutral Format (SVG) files as well as, or instead of VisoSchematic Diagram files. For a detailed description of the file formats that are monitoredwithin the above folders refer to theAdministrator Command Reference Manual.

Only PDMSDWG files that are associated with a DRAFT Database are propagated.Associated PDMSDWG Files are Sheet and Overlay drawings. Other DWG files, such asBacking Sheets and Symbols need to be propagated through Transfer of other Data. SeeTransfer of Other Data.

This is also the case for AVEVA Marine where there are drawings located in the ASSI,ASSP, BACK, BTEM, CPAR, MARK, NPLD, NSKE, PDB, PICT, PINJ, PLIS, PLJI, PPAR,PRSK, RECE, SETT, STD and WCOG directories.

10.6 Propagation of Inter-Database Macros

As in a non-Global projects, inter-DB macros will be created, for example, when a user triesto connect a pipe in one database to a nozzle in another database for which that user onlyhas Read access.

Within a Global environment, inter-db macros may need propagating to various locations. Inorder for this to be successful, the following must be ensured:

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

The project variables for the macro directory (for example, ABCMAC) are set for thedaemons. (All project environment variables must also be set for users, of course.)

10.7 Update Timings

It is extremely difficult to predict the length of time that an update will take to complete. It willdepend 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 updateperformance will be affected. The timings described below were undertaken on a line thathad no other process competing, and a line that was extremely clean - that is, its rate offailure would be near zero. On a normal WAN line, its collision and failure rate would notachieve anywhere near such a low level.

Final Designer Drawing {ABC} DWG

Marine Hull Drawingobjects (SDB files)

{ABC} DRG

Schematic Diagrams {ABC} DIA

Stencil {ABC} STE

Template {ABC} TPL


49/120



12.010:5

Update Timing Key

These test timings were taken when propagating 11080 pages (22695936 bytes) of databetween two machines.

10.8 Transfer of Other Data

Files such as ISODRAFT files, external PLOT files and DESIGN manager files are not

propagated automatically by the Global daemon. However, there is a mechanism in thedaemon to allow such files to be transferred to and from neighbouring locations. These filesare transferred by scheduled updates and the UPDATE ALLcommand.

The daemon uses environment variables to define import and export directories for otherdata files. At a location, there is a single directory to receive data imported from otherlocations; and a set of export directories, one per neighbouring location, from which datacan 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 transferfiles in these directories from one Satellite to another during scheduled updates (or when


50/120

12.010:6



the UPDATE ALL command is used). Files can only be transferred between neighbouringlocations, 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 neighbouringlocation BBB. The user at AAA must ensure that myfile has been placed in directory%EXP_BBB%. During the next scheduled update with BBB, this file will be sent to BBB, andreceived in directory %IMPORT% at location BBB. A user at BBB can then use myfile. Ifmyfileis to be sent on to other locations, it will need to be copied into the export directoriesat BBB for those locations.

Offline locations: The TRANSFER command only copies databases and picture files to orfrom 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 form,see below.

The script itself can be of any type of batch script, for instance perl, and can be as complexas required.

Batch Scripts


51/120



12.010:7

Note: Transferring of other Data uses the same communication line as Updates, and allother Global functionality. Over use of transferring too many other files may have animpact on the Window of Opportunity for updates.

10.9 Reverse Propagation Prevention

When a database update is initiated, a check is automatically made to ensure that theupdate direction is correct. If the check implies that the propagation is in the reversedirection (that is from out-of-date database to up-to-date database) the update is abortedand an error message 'Prevented reverse update' or 'Prevented reverse copying' isdisplayed. 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 theanalysis determines the appropriate propagation direction. This propagation direction iscompared 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 LatestSession. 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 pageat the secondary location is greater than at the primary location. This may be investigatedby checking the session number at each location, and, if necessary, by querying the HCCNTattribute at the DB elements of the databases.

The message 'Prevented reverse copying' means that the NACCNT at the secondarylocation is greater than at the primary location. This attribute may be queried at the DBelement 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 similarinvestigation can be made. For a system database the HCCNT and NACCNT attributesshould be queried at the STAT /*S element. For a Global database, they should be queriedat the GSTAT /*GS element.

To resolve the problem, the database at the appropriate location must be recovered.

You can find guidelines on how to recover from Reverse Propagation Errors in Recoveryfrom Reverse Propagation Errors.


52/120

12.010:8




53/120


Deleting Databases

12.011:1

11

Documents

Running Global Projects