Administrator Command Reference Manual

Administrator Command

Reference Manual

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

CopyrightCopyright 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 inthis 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

TrademarksAVEVA and Tribon are registered trademarks of AVEVA Solutions Ltd or its subsidiaries. Unauthoriseduse 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 Solutions Ltd

Administrator Command Reference ManualAdministrator Command Reference Manual

Contents Page

Reference ManualIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1How to Use This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:2

Stand-Alone DICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1DICE Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1DICE Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1

Reconfiguration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:112.0i

Reconfiguration Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1Starting up RECONFIGURER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1Administrative and Querying Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2Basic Reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2Reconfiguring a Single Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2Specifying the Source Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:3Specifying the Destination DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:4Specifying What Will be Copied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:4Starting the Reconfiguration Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:4Example of a Simple Reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:5

Using the SAMEREF Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:5Using the SESSIONS Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:6Listing the Reference Number Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:7

Administrator Command Reference ManualGlobal Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:7Controlling RECONFIGURER Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:7Copies and Reconfigured Copies of DBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:8Copies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:8Reconfigured Copies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:8

Advanced Reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:9References Between Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:9Updating References into a Reconfigured Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:10Saving the Reference Number Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:11Copying Parts of Databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:11Copying Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:13

Transferring Data Between Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:13Upgrading a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:14Reconfiguration Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:17Standard Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:17General Format of Pass 2 Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:18Codes Used to Identify Message Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:18

Database Transfers between Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:19Binary and Character Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:20Transfer Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:20Reconfiguring a Global Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:20Reconfiguring Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:21Outputting Changes Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:21The SAMEREF Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:21The SESSIONS Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:21Reconfiguring a Single Extract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:21Reconfiguring a Family of Extracts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:21The RCFUPDATE Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:22Example of Reconfiguring a Three Level Extract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:22Reconfiguring the Transaction Database in a Global Project. . . . . . . . . . . . . . . . . . . . . . . 3:24

System and Global Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1Structure of the Local System Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:2Structure of the Global Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:6

Transaction Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:1Structure of the Transaction Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:112.0ii

Administrator Command Reference ManualTRMSGW Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:2TRYEAR, TRMONT and TRDAY Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:3TRUSER and TRLOC Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:3TRINCO Element (Input Command) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:3TROUCO Element (Output Command). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:6TROPER Element (Operation). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:9TRMLST, TRSLST, and TRFLST Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:11TRMESS, TRSUCC, and TRFAIL Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:11

Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1Project Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1Project Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:2Global Project Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:3Module Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:4Font Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:4Querying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:4General PDMS Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:4Data Integrity Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:5Reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:5

Command Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1Conventions Used in the Syntax Graphs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1Notes on Syntax Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:3Detailed Descriptions of Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:3ACCESS (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:4ACRADD (Project definition). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:4ACRREM (Project definition). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:5ADD (Project definition). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:5ADMINISTER (Global Project Administration - Remote Administration) . . . . . . . . . . . 7:6ALLOCATE (Global Project Administration - Hub only) . . . . . . . . . . . . . . . . . . . . . . . . . 7:8ALPHA (General PDMS Command) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:10AUTHENTICATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:10AUTHUSERREM/OVE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:11BACKTRACK (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:11BRIEF (Reconfiguration). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:13CANCELCOMMAND (Global Project Administration). . . . . . . . . . . . . . . . . . . . . . . . . . 7:1312.0iii

Administrator Command Reference ManualCDESC (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:14CHANGE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:15CHECK (Data Integrity Checking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:18CHECKOPTION (Data Integrity Checking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:20CNAME (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:23COPY (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:24CREATE (Project definition). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:26CURRENT (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:32DADD (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:33DEALLOCATE (Global Project Administration - Hub only) . . . . . . . . . . . . . . . . . . . . . 7:34DEFER (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:36DELETE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:36DREMOVE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:39DUMP (Reconfiguration). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:39DUPLICATENAMES (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . 7:40EDIT (Module definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:41ERRORFILE (Data Integrity Checking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:43ERRORS (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:43EXCHANGE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:44EXCLUDE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:44EXPUNGE (Project Administration). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:45EXTERNAL (Data Integrity Checking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:47EXTRACT (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:48FINISH (General PDMS Command) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:50FONTDIRECTORY (Font definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:50FONTFAMILY (Font definition). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:51FROM (Reconfiguration). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:53FULL (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:54GENERATE (Global Project Administration - Hub only) . . . . . . . . . . . . . . . . . . . . . . . 7:54GETWORK (General PDMS Command). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:55HUBLOCATION (Global Project Administration - Hub only) . . . . . . . . . . . . . . . . . . . . 7:56INCLUDE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:57INITIALISE (Global Project Administration). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:57ISOLATION (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:58LIST (Querying) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:59LOAD (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:61LOCK (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:62MAKE GLOBAL (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:63MAXERRORS (Data Integrity Checking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:63MAXUSERS (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:6412.0iv

Administrator Command Reference ManualMAXWARNINGS (Data Integrity Checking). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:64MERGE CHANGES (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:65MESSAGE (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:67MODE (Data Integrity Checking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:68MODULE (Module Definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:69MOVE (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:70NEW (Project definition and Global Project Administration). . . . . . . . . . . . . . . . . . . . 7:71NEW STAMP (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:73PING (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:74PREVOWNER (Global Project Administration - Hub only). . . . . . . . . . . . . . . . . . . . . . 7:75PROJECT (Project definition). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:76PURGE (Project Administration and Global Project Administration) . . . . . . . . . . . . . 7:78QUERY (Querying) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:79RCFCOPY (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:84RCFUPDATE (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:86RCFUPGRADE (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:87RECONFIGURE (Reconfiguration). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:87RECOVER (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:88REINIT (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:91REMOTE (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:91REMOTEMESSAGE (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . 7:97REMOVE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:98RENEW (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:99REORDER (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:100REPAIR (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:100REPLICATE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:101RESETXREFS (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:104REVERT (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:104SAVEWORK (General PDMS Command) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:105SET (Project definition and Global Project Administration) . . . . . . . . . . . . . . . . . . . 7:106SORTALLOCATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:107STATISTICS (Data Integrity Checking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:107STATUSSESSION (Querying) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:108STOP (Data Integrity Checking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:108SYNCHRONISE (Global Project Administration). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:109SYSTAT (Querying) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:111SYSTEMLOCATION (Global Project Administration - Hub Only) . . . . . . . . . . . . . . . 7:113TADD (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:114TERM (General PDMS Command) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:115TO (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:11512.0v

Administrator Command Reference ManualTRANSFER (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:116TREMOVE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:118TTFONT (TrueType font definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:118UNLOCK (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:119UPDATE (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:120UPGRADE (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:123USERADD TO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:123USERREM/OVE FROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:124VB (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:124XREF (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:125

Drawing File Name and Folders. . . . . . . . . . . . . . . . . . . . . . . . . . . . .A:112.0vi

Administrator Command Reference ManualIntroduction1 Introduction

This manual describes the PDMS Administration commands for Standard (non-global) andGlobal projects. It is written for System Administrators who are already experiencedadministration users and who wish to write macros or use command input, rather than theGUI.

The content of this manual is based on the assumption that you are already familiar with theconcepts that a PDMS System Administrator needs to understand. If you are not familiarwith these concepts, you should refer to the relevant user guide, as follows:

Using PDMS Administration for a standard (non-global) project is described in theAdministrator User Guide, which tells you how to set up and administer PDMS projectsusing the GUI. The User Guide also describes the concepts that PDMS SystemAdministrators need to understand.

Using Plant Design Global via the GUI is described in the Global User Guide, whichalso describes the concepts in Plant Design Global that PDMS System Administratorsneed to understand.

Within the manual, commands that are only available in AVEVA Global are labelled asGlobal Project Administration Commands. Some of these commands are only available atthe Hub of a Global Project, and this is also shown. Some options in standard commandsare only available in Global Projects and these options are also indicated by 'Global' inassociated text.

This manual also describes how to use DICE, the PDMS Data Integrity Checker, outsidePDMS, as there is no GUI for the stand-alone module. It also describes databasereconfiguration, which is also a command line or macro operation.

1.1 MacrosMost people who read this manual will be writing macros, either to run into PDMS whenrequired, for example, to create a new project, or as part of customising the ADMINinterface.

There are some commands in ADMIN which automatically create simple PDMS macros.These are command files which can be read back into PDMS. In particular, you can use theREPLICATE command to create a macro which will replicate a project.12.01:1

For information about writing more complicated macros using the PDMS ProgrammableMacro Language, (PML), see the Software Customisation Guide and the SoftwareCustomisation Reference Manual.

Administrator Command Reference ManualIntroduction1.2 How to Use This ManualStand-Alone DICE applies to Standard and Global projects and describes how to run thePDMS Data Integrity Checker, DICE, from outside PDMS. This chapter is included in theCommand Reference manual as there is no interface to stand-alone DICE, and you willneed to enter commands interactively or via a macro.

Reconfiguration, applies to Standard and Global projects and describes databasereconfiguration.

System and Global Projects, applies to Standard and Global projects. It contains maps ofthe System Database and Global Database Hierarchies, and a list of the ADMIN elementsand their attributes that can be set explicitly by the user.

Transaction Database applies to Global projects only, and describes the transactiondatabase, the elements in it, and their attributes.

Command Summary applies to Standard and Global projects. It lists the ADMIN commandsin functional groups.

Command Details, applies to Standard and Global projects. It occupies the majority of themanual and describes every ADMIN command. The descriptions appear in alphabeticalorder of command names.

Drawing File Name and Folders file name conventions used for Drawing and Picture filesduring propagation.12.01:2

Administrator Command Reference ManualStand-Alone DICE2 Stand-Alone DICE

The Data Integrity Checker (DICE) can be run as a stand-alone program outside PDMS.This may be necessary if the System database has been corrupted, and you cannot enterPDMS.

Stand-alone DICE is started up using the script named dop, supplied in the PDMSEXEdirectory. Give the following command, outside PDMS:

$PDMSEXE/dopFor a summary of the commands that you can use in DICE, see the Data Integrity Checkingcommands in Command Summary.

Commands to exit from DICE in stand-alone mode are:

STOP FINISHYou can send the reports generated by DICE to a named file in your working directory usingthe ALPHA command.

2.1 DICE ErrorsPDMS obtains the text of all its user messages from an external file. When DICE is usedfrom within a PDMS project, this file is automatically available, but this is not the case instand-alone mode. Hence the next command you must give in stand-alone mode is theERRORFILE command, followed by the name of the error message file. For example:

ERRORFILE /%PDMSEXE%/MESSAGE.DATNote: This file will contain error messages referring to the operation of DICE itself, not any

errors DICE has found during the checking process

The default name of the message file can be found from the entry for DICE in the currentversion of makmac.mac, the project configuration macro.

2.2 DICE Commands12.02:1

Set up the options you require using the following commands (see the appropriatecommand pages for details):

ERRORFILE MODE MAXERRORS MAXWARNINGS STATISTICS

Administrator Command Reference ManualStand-Alone DICEYou can send the reports generated by DICE to a named file using the ALPHA command.

You can check one or more DB files by using the CHECK command. In this mode, you canonly refer to databases by their external filenames rather than by their internal PDMS DBnames. Up to ten files may be specified in a single command.

Note: The EXTERNAL command cannot be used in stand-alone mode (or by REMOTECHECK), because only one DB file can be accessed at a time.12.02:2

Administrator Command Reference ManualReconfiguration3 Reconfiguration

PDMS RECONFIGURER is run from within ADMIN, but only by using the command line.

In order to understand why database reconfiguration may be necessary, and to appreciatethe steps involved, it is helpful to have some knowledge of PDMS database structures andtheir management. For a summary of this information, including an explanation of DDLs(Database Description Languages) and DABACON (the DAtaBAse CONtrol program), readthe chapter Database Management System in the Administrator User Guide.

3.1 Reconfiguration ProcessReconfiguration is a two-pass operation, acting on either a complete database or onspecified parts of one.

In the first pass, RECONFIGURER scans a named source database and copies the datafor some or all existing elements and their attributes into intermediate files.

In the second pass, the contents of the intermediate files are transferred to a specifieddestination database.

This mode of operation has the following features: Only existing elements are copied to the intermediate files; deleted items and corrupt

data are ignored. The destination database created from these files is therefore bothcompact and uncorrupted.

The reference and non-reference attributes of the elements are held in differentintermediate files. The method of transfer of data to the destination database ensuresthat all referencing is complete and consistent.

The source and destination databases may have different DDLs. This enables existingdata to be restructured to conform to a new database structure and so, for example, tobe used with a new version of PDMS.

Reconfiguration can used to transfer a project to different hardware. The intermediatefiles produced by the first stage can be decoded into a portable format (typically ASCII),and transferred, and then the second stage carried out.

A similar technique is used to convert whole projects to new versions of PDMS, though inthis case the intermediate files need not be decoded. 12.03:1

3.2 Starting up RECONFIGUREREnter PDMS in non-graphics (tty) mode by typing:

pdms ttyThen specify the Project and User ID/Password, and enter ADMIN. For example:

Administrator Command Reference ManualReconfigurationproj ABCuser SYSTEM/XXXXXXadmin

You can now start to set up the reconfiguration parameters using the commandssummarised in the Command Summary under Reconfiguration.

3.3 Administrative and Querying CommandsSome of the general PDMS and querying commands, which are particularly relevant toreconfiguration, are summarised below.

3.4 Basic Reconfiguration

3.4.1 Reconfiguring a Single DatabaseThe simplest reconfiguration involves a single DB which has no references into it from otherDBs; for example, a Design DB which has no associated Drawing (PADD) DBs.

A simple reconfiguration requires a source and a destination DB. When the process hasbeen completed, the source DB will remain unchanged, and the destination DB will containa compacted copy of the parts of the source which were specified in the copy list.

SYSTAT Gives information about the current active status of theproject within which you are working.

LIST Lists project information; there are a variety of options.SET TEAM Sets the specified team as the current one.LOCK, UNLOCK Locking the System Database prevents any new users

entering the project.MESSAGE Sends messages to other users.Q DB Gives the type, number and filename of the specified DB

and a list of the MDBs of which it is a member. For example:

Q DB CIVIL/JBX37CCIVIL/JBX37C DESI NUMBER 6 FILENAME /TVX000/TVX009MDBS: /LAYOUT /TANKS

Q COPIES Lists all DBs which are copies of the specified DB. Forexample:

Q COPIES CIVIL/JBX37CDB CIVIL/JBX37C HAS COPIES: CIVILl/JBX47C

Q MDB Lists the DBs in the specified MDB.Q TEAM Lists the users who are members of the specified team plus

a list of the DBs owned by the team.Q SET TEAM Gives the name of the currently set team if any.Q LOCK Shows whether the project is locked.12.03:2

Administrator Command Reference ManualReconfigurationThe transfer of data takes place in two passes, the second of which is further divided intotwo phases:

The reason for the two phases is that references in the source DB may refer to elementslower down in the hierarchy. It is necessary, therefore, to create all elements in thedestination DB before trying to set references to any of them.

Since the two passes perform independent and consecutive operations, the process can beinterrupted after Pass 1 has been completed, with Pass 2 being run later.

Reconfiguration has four basic steps:

1. Specify where the data to be reconfigured is coming FROM 2. Specify where the reconfigured data is going TO.3. Specify which parts of the source data are to be copied to the destination.4. Start the reconfiguration process.

3.4.2 Specifying the Source DatabaseThe source of the data to be copied is specified using the FROM command. Someexamples of the use of FROM are:

PASS 1 The data is read from the source DB and written to a pair ofintermediate files. The first file holds the element structuresand the non-reference attributes, the other holds thereference attributes.

PASS 2 - Phase 1 The first file is read by RECONFIGURER and used torecreate the original structures in the destination DB,including setting of the non-reference attributes.

PASS 2 - Phase 2 The second intermediate file is read and its contents used toset all reference attributes in the destination DB and toperform insertion operations.

Examples:

FROM DB STEELS/STEELSSource data is in database STEELS/STEELS in current project

FROM PROJECT XXX STEELS/STEELSource data is in specified DB in project XXX

FROM DBFILE /abc016Source data is in specified file (assumes project directory is current directory)12.03:3

Administrator Command Reference ManualReconfiguration3.4.3 Specifying the Destination DBThe destination of reconfigured data is specified using the TO command. Some examples ofthe use of TO are:

TO DB and TO DBFILE specify that the data are to be reconfigured into an existing DB,identified by its name or that of the file containing it. The destination DB must be of the sametype as the source DB, and will normally be empty, but need be. For an explanation of whathappens when the DB is not empty, see Copying Parts of Databases.

TO NEW specifies that a new DB is to be created to receive the reconfigured data. This isthe most common option for the general compaction of DBs. It is explained further in Copiesand Reconfigured Copies of DBs.

Note: The new database will need to be added to the appropriate MDBs.

3.4.4 Specifying What Will be CopiedThe RCFCOPY command specifies which parts of the source DB are to be copied to thedestination. Most commonly a whole DB is reconfigured, using the command option:

RCFCOPY ALLThe RCFCOPY ALL command copies all elements in the list part of the World element ofthe source DB into the World element of the destination DB. World itself is not copied. Partsof a database can be copied by using the RCFCOPY command followed by the name of theelement at the top of the hierarchy to be copied. Only elements that can be owned by World,for example, Sites, can be specified. The list of elements specified by the RCFCOPYcommand becomes the copy list.

Note that you must use RCFCOPY ALL if you intend to use the RECONFIGURESESSIONS command at the next step, as the SESSIONS option is not valid if you only carryout partial reconfiguration.

3.4.5 Starting the Reconfiguration ProcessThe reconfiguration process is started by giving the command:

RECONFIGURE (minimum abbreviation RECON)Messages are output to indicate the successful start and completion of each stage. Whenthe process is complete, all information concerning the source, destination, copy list and the

Examples:

TO DB STEELS/STEELSReconfigured data to go to database STEELS/STEELS in current project

TO NEW HVAC/HVAC DBNO 777Reconfigured data to go to new database USERM/DESIGN, number 777, in currentproject

TO DBFILE /des008Reconfigured data to go to specified file (assumes project directory is currentdirectory)12.03:4

Administrator Command Reference ManualReconfigurationextent of information output is deleted, ready for another reconfiguration operation ifrequired.

You must specify the source, destination and copy list for each reconfiguration.

The output by default is sent to the screen, but you can send it to a file by giving the ALPHAFILE command, followed by a filename, before reconfiguration.

You can use the following options with RECONFIGURE: Use the SAMEREF option to ensure that the same reference numbers are maintained

after reconfiguration. See Using the SAMEREF Option, for details. Use the SESSIONS option to ensure that the session information stays the same after

reconfiguration. See Using the SESSIONS Option for details.

3.4.6 Example of a Simple ReconfigurationThe following command sequence might be used to reconfigure a DB which is notreferenced by any other DBs:

FROM DB MASTER/DESIGNTO DB MASTER/DESNEWRCFCOPY ALLRECONFIGURE

Note: In practice it would be advisable to use RCFUPDATE and DUMP in the commandsequence. See Updating References into a Reconfigured Database and Saving theReference Number Index.

The following messages are typical of the output during a completely successfulreconfiguration:

*** Pass one initiated ****** Pass one completed ****** Pass two initiated ***

EC SITE #32/202 =42/205 Phase one complete - starting phase two *** Pass two completed *** ***Reconfiguration Completed0 Elements were not defined in DDL0 Elements have been lost0 Elements are no longer named0 Attributes were incorrectly defined0 Elements were not inserted.

See Reconfiguration Messages, for a complete list of output messages.

3.5 Using the SAMEREF OptionWhen a DB is reconfigured, the reference numbers of the elements in the destination DBwill be different from the corresponding reference numbers in the source DB. To ensure that12.03:5

Administrator Command Reference ManualReconfigurationthe same reference numbers are maintained after reconfiguration, you can use thecommand:

RECONFIGURE SAMEREFIn this case the destination DB number must be the same as the original one. This meansthat you will have to delete the source database, and create a new one with the samenumber.

The following example illustrates the use of the SAMEREF option:

FROM DB MASTER/DESIGNTO FILE /F1 /F2RCFCOPY ALLRECONFIGUREDELETE DB MASTER/DESIGNCREATE DB MASTER/DESIGN DESI DBNO nnFROM FILE /F1/F2TO DB MASTER/DESIGNRECONFIG SAMEREF

3.6 Using the SESSIONS OptionWhen a DB is reconfigured, by default the session information from the source DB is notpreserved. To ensure that session information such as the original session comment,session number, username and original date stays the same after reconfiguration, you canuse the command:

RECONFIGURE SESSIONSThe option is not valid for SYSTEM, or GLOBAL DBs, and is not available for a partialreconfiguration.

The following example illustrates the use of the SESSIONS option:

FROM DB CTBATEST/DESITO FILE /A /BRCFCOPY ALLRECONFIG SESSIONS

After reconfiguration, data can be read back in from the file using the existing commands,replacing the original DB data. When reading in data, the DB number and extract numbermust be the same as the originating DB number and extract number. For example:

FROM FILE /A /BTO DB CTBATEST/DESIRECONFIG

The SAMEREF option is assumed when reading the data. If errors occur, the data is notsaved. If you want the data saved even if errors occur, use the FORCE option. For example:

FROM FILE /A /BTO DB CTBATEST/DESIRECONFIG FORCE12.03:6

Administrator Command Reference ManualReconfiguration3.7 Listing the Reference Number IndexWhen a DB is reconfigured without the SAMEREF option, the reference numbers of theelements in the destination DB will be different from the corresponding reference numbers inthe source DB.

An index of the reference numbers of elements in the new DB against those in the old DB isautomatically created as an essential part of the reconfiguration process. The new referencecorresponding to an old reference can be queried using the command:

Q NEWREF refnowhere refno is the new reference number. The old reference number will be returned. Forexample:

Q NEWREF #32/202 =42/205

3.8 Global ProjectsIn a Global project, you can reconfigure the System and Global databases. The commandsare:

FROM SYSTEMRECONFIGURE

(The above command also works in a non-Global project.)

FROM GLOBALRECONFIGURE

In both these cases, the existing System or Global databases will be overwritten, so you donot give a TO command. The COPY ALL and SAMEREF options are also implied.

In a Global project, you can only give a RECONFIGURE command for a System or Globaldatabase if you are at the primary location of the database:

For a Global database, the primary location is the Hub. For a Satellite System database, the primary location may be at the Satellite itself, or it

may be at another Satellite, or at the Hub. The RECONFIGURE commandreconfigures the currently open System database. At a Satellite, the command cantherefore operate either on the local System database, or on another Satellites Systemdatabase which is primary at the local Satellite.

3.9 Controlling RECONFIGURER OutputYou can control the format and extent of the output produced by RECONFIGURER duringPass 2 processing. The commands are:

In VB (Very Brief) mode, a message is output as each element in the copy list issuccessfully created. If the copy command was RCFCOPY ALL, then a message is output

VB Very brief output modeBRIEF Brief output modeFULL Full output mode12.03:7

for each element successfully copied into the World of the destination DB.

Administrator Command Reference ManualReconfigurationIn BRIEF mode, all information output in VB mode is given, plus messages describing anyerrors that have occurred due to DDL changes.

In FULL mode, all information output in BRIEF mode is given, plus a log of all elementssuccessfully created and named. Note that FULL mode is very verbose and its use is notgenerally recommended.

The default is BRIEF mode.

An upper limit may be set on the number of errors that are acceptable during Pass 2 of areconfiguration using the ERRORS command. For example:

ERRORS 50If the specified limit is reached, reconfiguration is abandoned and the DB is left unaltered.

By default, RECONFIGURER allows an unlimited number of errors to occur. This situationmay be reset if necessary by using the ERRORS command followed by a negative value.For example:

ERRORS -1

3.10 Copies and Reconfigured Copies of DBsThere are two ways of copying a DB in PDMS, which create two different types of copy:copies and reconfigured copies. This section explains the difference.

3.10.1 CopiesA copy of a DB can be made by using the RCFCOPY command. For example the followingcommand: will create a copy of the existing DB PIPEA/PIPEA in the new DB ADMIN/TEST.

RCFCOPY PIPEA/PIPEA ADMIN/TESTThe key features of copies are:

All copies of DBs have the same DB number. This may be seen by using the LISTFILES command. For example:

There is no implied direction of copying. Thus, in the previous example, PIPEA/PIPEAand ADMIN/TEST are each a copy of the other.

The contents of all copies are identical with respect to both data and structure. Any given element has the same reference number in each copy. A DB may have any number of copies, but copies may not exist in the same MDB.

3.10.2 Reconfigured CopiesA reconfigured copy is one named by the TO DB or TO NEW commands. The key featuresof reconfigured copies are:

MASTER/DES DESI NUMBER 14 FILENAME /%DRA000%/dra013 UPDATEPIPEA/PIPEA DESI NUMBER 2 FILENAME /%DRA000%/dra001 UPDATEADMIN/TEST DESI NUMBER 2 FILENAME /%DRA000%/dra003 UPDATEUSER/DRAFT PADD NUMBER 5 FILENAME /%DRA000%/dra004 UPDATE12.03:8

A reconfigured copy has a different DB number from that of the source DB.

Administrator Command Reference ManualReconfiguration In the reconfiguration process, the destination DB becomes a reconfigured copy of thesource DB, but the reverse is not true. The relationship exists in one direction only.

The contents of a reconfigured copy are an edited version of those of the source DB. Any given element will have a different reference number in the reconfigured copy from

its reference number in the original DB (unless you use the same SAMEREF option).

3.11 Advanced ReconfigurationThe previous sections in this chapter describe how a single DB can be reconfigured. In areal PDMS project, with many DBs of different types and with reference attributes pointingfrom one DB to several other DBs, reconfiguration is usually a more complex process.

This section describes how one or more DBs can be reconfigured in such an environment. Italso describes how part of a DB can be reconfigured, rather than the whole DB.

Note: If the SAMEREF option is used, the reconfiguration is much simpler

3.11.1 References Between DatabasesA DB often contains elements which have reference or reference array attributes whichpoint into other DBs. For example, one Design DB could contain a Branch connected to aNozzle in another Design DB. The HREF (or TREF) attribute of the Branch would point intothe second DB and the CREF attribute of the Nozzle would point back into the first DB. Seeexample below:

Similarly, references can exist from Design DBs into Catalogue DBs (the SPREF attribute ofa piping component pointing to an SPCOM, for example), but references cannot exist from aCatalogue DB back into a Design DB.

When a DB is reconfigured without the SAMEREF option, most of the reference numbers ofits elements will change. To maintain the integrity of pointers into the DB from other DBs,the contents of any DB which might point to elements in the reconfigured DB are scannedand the reference or reference array attributes are changed to point to the correct elementonce more.

For example, assume that the reference number of an SPCOM in a Catalogue DB changesfrom =17/3108 in the original DB to =49/2014 in the reconfigured copy. All pipingcomponents whose SPREF attribute was previously set to =17/3108 must have SPREFreset to =49/2014. Such components might exist in several DBs.

Reference resetting is performed by the RCFUPDATE command described in the nextsection.

DESIGN DB 1

DESIGN DB 2

Branch /150-B1

Nozz /E1-N2

CREF /150-B1

HREF /E1-N212.03:9

Administrator Command Reference ManualReconfiguration3.11.2 Updating References into a Reconfigured DatabaseWhile a DB is being reconfigured without the SAMEREF option, RECONFIGURER builds upan index of the reference numbers of all elements in the source DB versus theircorresponding new reference numbers in the destination DB. The RCFUPDATE commanduses this index to check reference pointers in other DBs and update them to point to thecorrect elements in the reconfigured DB. Examples of the use of this command are:

Note: The RCFUPDATE command must be given immediately following a RECONFIGUREoperation.

As the RCFUPDATE command may cause a DB to be written to, you must have Read-Writeaccess to all relevant DBs. The DBs must not be in active use by any other user of theproject.

Care should be taken when reconfiguring to the same DB number. If you update a DB twice,the resulting reference numbers could be wrong. For example:

Thus, giving the RCFUPDATE command twice results in the reference =123/456 being resetto =123/458.

RECONFIGURER knows which types of DB can be pointed to by reference attributes inother types of DB, and so does not attempt to update DBs which could not possibly point tothe latest reconfigured copy. A report is output which lists which DBs were and which werenot updated.

The table of references is maintained across multiple reconfigurations, as long as you donot exit from ADMIN.

Examples:

RCFUPDATE DB MASTER/DESIGNUpdates references to the reconfigured DB from DB MASTER/DESIGN.

RCFUPDATE DB MASTER/DESIGN INTERNALUpdates references in DB MASTER/DESIGN for any elements that have beencopied with RCFCOPY ALL CONNECTIONS. Use this option with care because it ispossible to update a reference that has already been changed by theRECONFIGURE command.

RCFUPDATE MDB /USERAUpdates all references to the reconfigured DB from DBs in MDB /USERA.

RCFUPDATE TEAM USERUpdates all references to the reconfigured DB from DBs owned by team USER.

Old reference New reference

/VESS1 =123/456 =123/457

/VESS2 =123/457 =123/45812.03:10

Administrator Command Reference ManualReconfiguration3.11.3 Saving the Reference Number IndexThe RCFUPDATE command is usually given immediately after databases have beenreconfigured. The index can be saved to a file when the reconfiguration has beencompleted; to be used at a later date.

The commands are DUMP to save to a file, and LOAD to load a file. For example:

LOAD /DUMP1FROM DB MASTER/DESIGNTO DB MASTER/DESNEWRCFCOPY ALLRECONFIGUREDUMP /DUMP2

These commands will read an existing reference number index from file /DUMP1, add thereference number pairs from the specified reconfiguration to it, and then write the index outagain to the file /DUMP2.

If a number of databases have been reconfigured, the dump file will record the cross-reference index for all of them.

The LOAD command replaces the current index. The command LOAD APPEND appendsthe table to the current index.

3.11.4 Copying Parts of Databases The RCFCOPY ALL command copies all the elements in the source DB World into thedestination DB World. If the World of the destination DB already contains members, then theelements from the source DB are added to these.

The RCFCOPY command can be used to define the root elements to be copied. A rootelement is any element owned by the World, that is:

When a root element is copied, all elements owned by it are also copied. A maximum of 300root elements may be specified in a single copy list.

The selective commands RCFCOPY CATALOGUE and RCFCOPY SPECIFICATIONScause the first root elements of type CATA and SPWL, respectively, to be copied from thelist part of the World in the source DB.

To copy only part of a DB, one or more root elements must be specified (by name orreference number) in a RCFCOPY command. For example:

RCFCOPY /SITE-A SITE-7Elements of any other types will be copied into the destination DB as NULL elements, that isthey will be created as floating elements, not owned by any higher-level element. This doesnot mean that they are inaccessible. As long as such an element is named (or you know itsnew reference number) it can be incorporated as a member of any suitable parent elementby using the INCLUDE command.

BLTA CASW CATA CCTA CMPW CONW DEPTGPWL LIBY MATW RUNW SITE SPWL UNIT UWRL12.03:11

Administrator Command Reference ManualReconfigurationIf you are not at a top level element, there must be an existing element in the destination DBinto whose list part you wish to incorporate the element being copied. This is done using theINTO option of the RCFCOPY command. For example:

RCFCOPY /ZONE5A INTO /SITE-3would copy the Zone /ZONE5A and make it the last member of the Site /SITE-3.

If the intended owning element does not already exist in the destination DB at thebeginning of Pass 2, the listed root element will not be copied. For example:

RCFCOPY /SITE-3 /ZONE5A INTO /SITE-3is not allowed.

INTO cannot be used when the destination is FILES rather then a DB. The word AND andthe comma (,) may be used as separators to improve readability, thus:

RCFCOPY /SITE-5, /ZONE5A INTO /SITE-3, /SITE-6 AND /SITE-12Several RCFCOPY commands can be given in sequence to add elements to the copy list.For example, the sequence

RCFCOPY /SITE-5RCFCOPY /ZONE5A INTO /SITE-3RCFCOPY /SITE-6, /SITE-12

is exactly equivalent to the RCFCOPY command in the previous example.

If an element is quoted in the copy list but does not exist in the source DB, an error messageis output and the element is not copied. Since RCFCOPY commands are additive, acorrecting command may be given on the next line. For example:

RCFCOPY /SITE1 /SITE2 /SITR3 /SITE4(24,16) SITR3 not found (error message)

Since SITE1, SITE2 and SITE4 are already in the copy list, all that is needed to add SITE3is:

RCFCOPY /SITE3Note: Partial reconfiguration of PADD DBs is only allowed for picture elements (i.e. SHEE,

BACK, OVER, SYLB, LALB) and above.

Setting External References

In cases where you have made a partial copy of a database, sometimes it is necessary foryou to ensure the external references are correct in the copied elements.

For example, if you moved a piping zone to a different database while maintaining thereferences to an equipment zone which was to remain it the original database, the copiedpiping zone could have unset external references and the equipment zone would remainconnected to the original piping zone.

In these cases you can use the ALLCONnections option to set the external references forthe reconfigured elements:

RCFCOPY /SITE1 INTO /SITE2 ALLCONNECTIONSThis will set all references including those within the original database not in the list ofcopied elements.12.03:12

Administrator Command Reference ManualReconfigurationTo update the references of the original database to point to the new copied elements usethe RCFUPDATE INTERNAL command described in Updating References into aReconfigured Database.

3.11.5 Copying GroupsIf a Group World is specified in a RCFCOPY command, only the Group World and its ownedGroups are copied. Errors will occur in Phase 2 if the Group members have not be copiedas well.

It is meaningless to try to reconfigure a group on its own.

3.12 Transferring Data Between ProjectsRECONFIGURER provides a simple means of transferring data from one project to another,on the same type of computer, provided both projects are running under the same majorversion of PDMS and provided cross-referencing between DBs is considered logically.

The transfer operation in this case requires the use of the FROM FILES and TO FILESoptions of the FROM and TO commands. In the simplest case, namely the transfer of thecontents of a single DB, such as a Catalogue, the following sequence of commands couldbe used:

In the source project:

and in the destination project:

Example:

FROM DB /CATOLDSpecify source DB.

TO FILES /TEMP1 /TEMP2Only pass 1 of reconfiguration to be carried out; partially reconfigured data to bestored in named files.

RCFCOPY ALLRECONFIGURE

Example:

FROM FILES /TEMP1 /TEMP2Partially reconfigured data to be recovered from named file;

TO DB /CATNEWpass 2 of reconfiguration to be done.

RCFCOPY ALLRECONFIGURE12.03:13

Administrator Command Reference ManualReconfigurationNote: FREE (i.e. Read/Write) access is required to both projects.

If the contents of more than one DB are to be transferred, provided no reference attributespoint outside the set of DBs being transferred, an extension of the same procedure could beused. Consider the transfer of the whole of one Design DB, the whole of a Catalogue DBand one item of equipment from a second Design DB, thus:

The reconfiguration commands should be given in the following order:

In the source project:

and in the destination project:

3.13 Upgrading a ProjectThe XREF and RESETXREFS commands described in this section are intended for useduring the upgrading of a project from one version of PDMS to the next. They operate on the

Source DB Elements Transferred Destination DB

CIVIL/STRUC4 Whole Design DB STEEL/MAIN

ANSI/MASCAT Whole Catalogue DB CATAL/MAIN

SITE-A One Site EQUIP/MAIN

FROM DB ANSI/MASCATTO FILES /REC1A /REC1BRCFCOPY ALLRECONFIGURE

Copies the Catalogue DB first

FROM DB CIVIL/STRUC4TO FILES /REC2A /REC2BRCFCOPY ALLRECONFIGURE

Copies the Design DB

FROM DB VESSEL/V25CTTO FILES /REC3A /REC3BRCFCOPY /SITE-ARECONFIGURE

Copies the Site

FROM FILES /REC1A /REC1BTO DB CATAL/MAINRECONFIGURE Creates Catalogue DB

FROM FILES /REC2A /REC2BTO DB STEEL/MAINRECONFIGURE Creates Design DB

FROM FILES /REC3A /REC3BTO DB EQUIP/MAINRECONFIGURE Creates equipment item

RCFUPDATE DB STEEL/MAINRCFUPDATE DB EQUIP/MAIN

Gives correct cross-references12.03:14

Administrator Command Reference ManualReconfigurationdata during its transfer from the source DB to the destination DB such that the data can bemodified to conform to the requirements of a new DDL.

The commands are used to ensure that all cross-references are correctly set after a multi-DB reconfiguration. They are particularly useful in the case where two databases of thesame type are referencing each other. They are also useful when copying between projects,as an alternative to the UPDATE command. When copying between DBs with the same DBnumber, it is best to use XREF and RESETXREFS.

These commands are normally handled automatically by the upgrade macros supplied witha new version of PDMS. They may be used independently of the upgrade macros by theexperienced user, preferably after consultation with AVEVA Solutions Ltd, and it is for thisreason that they are described here.

XREF may be used to generate a list of the reference numbers of all elements which needupdating for each DB. The list is created during the restructuring of the new DBs in Phase 2of Pass 2.

This list is then used to monitor a partial updating operation, which ensures that allreferences are reset into every element which has been affected by a DB reconfiguration.The partial update is controlled by the RESETXREFS command, which is related to theRCFUPDATE DB command. The RESETXREFS function applies only to elements whosereference numbers appear in the corresponding XREF file.

For example:

RESETXREFS WITH /REFFILE RESOLVE DB MASTER/DESNEWRESET /REF2 RESOL /NEWDB

Here /REFFILE is the name of the file generated by the XREF command and MASTER/DESNEW is the corresponding DB to be updated.

In effect the RESETXREFS command opens the specified XREF file and the RESOLVEcommand part initiates the appropriate update. The macro files generated by theUPGRADE command in ADMIN ensure that the RESET filenames are correctly matched tothe corresponding RESOLVE dbnames.

Note: The XREF file only indicates those elements which need to be updated. The DUMPfiles are still required in order to match the old and new reference numbers correctly.

When reconfiguring a whole project, it is impossible to order databases of the same type sothat all references are resolved as the reconfiguration proceeds. The XREF andRESETXREFS commands are needed to tidy up the references.

Note: The UPGRADE command is used when a project is being upgraded from an earlierversion of PDMS.12.03:15

Administrator Command Reference ManualReconfigurationThe following is an example of a sequence of commands:

A more general command sequence for a project upgrade is shown in the following inputand output macros:

Input macroWrite Upgrading project CJB Write From PDMS10 to PDMS11 Write Input phase $R6Checkddl is 11To db STANA/SAPROPFrom files /REC1A /REC1BXref /REC1XReconfigureTo db DEREKF/DFPROPFrom files /REC2A /REC2BXref /REC2XReconfigureTo db ALANC/ACPROPFrom files /REC3A /REC3BXref /REC3XReconfigureTo db TAMH/THPROPFrom files /REC4A /REC4BXref /REC4XReconfigureTo db TAMH/PROP_ATESTFrom files /REC5A /REC5BXref /REC5XReconfigureReset with /REC1XResolve db STANA/SAPROPReset with /REC2XResolve db DEREKF/DFPROPReset with /REC3XResolve db ALANC/ACPROPReset with /REC4XResolve db TAMH/THPROPReset with /REC5XResolve db TAMH/PROP_ATEST

Example:

TO DB XX/A2FROM DB XX/A1XREF /XX1RCFCOPY ALLRECONFIG

::

TO DB XX/B2FROM DB XX/B2RCFCOPY ALLRECONFIGRESET WITH /XX1 RESOLVE DB XX/A212.03:16

Finish

Administrator Command Reference ManualReconfigurationOutput macroWrite Upgrading project CJB Write From PDMS10 to PDMS11 Write Output phase $R6UPGRADE ONFrom db STANA/SAPROPTo files /REC1A /REC1BCopy allReconfigureFrom db DEREKF/DFPROPTo files /REC2A /REC2BCopy allReconfigureFrom db ALANC/ACPROPTo files /REC3A /REC3BCopy allReconfigureFrom db TAMH/THPROPTo files /REC4A /REC4BCopy allReconfigureFrom db TAMH/PROP_ATESTTo files /REC5A /REC5BCopy allReconfigure

3.14 Reconfiguration MessagesDuring the various stages of the reconfiguration process, messages will be output. This isparticularly so during Pass 2, in which the data from the intermediate files is used toreconstruct the element hierarchy in the destination DB.

In the simplest case these messages will just indicate the start and finish of each phase, andconfirm that all elements and their attributes were correctly placed. In a more complex caseit is probable that a number of error messages will also be output, indicating potentialproblems in building up an unambiguous structure in the new DB.

3.14.1 Standard Information MessagesThe progress-monitoring messages, which indicate the stages reached during thereconfiguration, are self-explanatory. They are:

*** Pass one initiated ****** Pass one completed ****** Pass two initiated ***:*** Pass two completed ******Reconfiguration Completed

After the reconfiguration has been completed, a summary of any problems found duringPass 2. This will contain zero values where no problems were found.12.03:17

Administrator Command Reference ManualReconfigurationThe format of this report is:

where integer is the relevant number.

3.14.2 General Format of Pass 2 Error MessagesIn addition to the standard information messages described above, a range of errormessages may be generated during Pass 2. These messages have the general format:

CODE TYPE OLDREF NEWREF NAME

although some parts of this may be omitted.

For example:

EN EQUIP #10/21 =12/12 /NEWNAME#EAE SHEE #88/842 =16/2417 /DR1/S5*ENID SITE #15/23 The individual parts of the message are:

3.14.3 Codes Used to Identify Message TypesThe coded prefix to each message comprises two parts. The first character is one of thefollowing:

A space indicates information rather than an error An asterisk (*) indicates an error concerning the creation or naming of an element A hash (#) indicates an error concerned with an attribute

The remaining characters, which give more explicit meaning to the message, are explainedin the following subsections.

Integer Elements were not defined in the DDL

Integer Elements have been lost

Integer Elements are no longer named

Integer Attributes where incorrectly defined

Integer Elements were not inserted

CODE: Identifies the nature of a message arising from the creation or naming ofan element. The codes used are detailed in the next section.

TYPE: The type of element, e.g. SITE, BRAN, SHEE etc.OLDREF The reference number of the element in the source DB (starting with #).NEWREF: The reference number of the corresponding element created in the

destination DB (starting with =). This will be blank if the element couldnot be created.

NAME: The name given to the element. This applies only if the message iscoded EN to indicate that the element has been named (see nextsection).12.03:18

Administrator Command Reference ManualReconfigurationInformation-only Messages (prefix: space)

There are two possible codes:

These are output as the reconfiguration proceeds and each message ends with the name ofthe copied element.

Error Messages Relating to Elements (prefix: asterisk)

The element could not, therefore, be created. This can occur when the element type is notpermitted in the list part of the element above it in the DB hierarchy, for example, if anattempt is made to reconfigure FROM FILES into a DB of the wrong type.

An attempt was made to insert the element into a list where it is no longer permitted.

Elements in the list part of ones that cannot be created are lost, since they cannot becreated either.

Error Messages Relating to Attributes (prefix: hash sign)

These all begin with

followed by one or more other messages giving more information about the error.

3.15 Database Transfers between ComputersNote: The hardware platforms currently supported allow binary compatibility of databases,

and so the information in this section will not usually be needed.

RECONFIGURER can be used for the transfer of PDMS DBs between different computers,which may be of different types. Because reconfiguration is a two-pass operation, the datacan be copied from one computer and read back into a different one.

The transfer operation is essentially an extension of the procedure for copying data betweenprojects, described in Transferring Data Between Projects. RECONFIGURER makesprovision for translating the coding of the intermediate files to ensure compatibility betweenthe language requirements of different computers.

An alternative method of transferring data between different computers is to use theOUTPUT command in DESIGN, DRAFT, PARAGON or LEXICON. For details of other data

EC Element CreatedEN Element Named

*ENID Elements Not In DDL

*ENI Element Not Inserted

*EL Element Lost

#EAE Element Attribute Error12.03:19

transfer methods, see the DESIGN Reference Manual Part 1 (OUTPUT command).

Administrator Command Reference ManualReconfiguration3.16 Binary and Character Files Data can be stored in two formats:

Binary files are in a compact machine-readable form, but are generally specific to aparticular type of computer.

Character files (which are usually in ASCII code) generally have to be much larger tohold the same amount of information, but are human-readable. Character files can betransferred relatively easily between different types of computers.

PDMS DBs are stored as binary files so that large amounts of data can be held efficiently.RECONFIGURER provides a means to convert PDMS DBs from binary files into characterfiles and vice versa.

3.17 Transfer ProcessThe files used by the transfer process are not the PDMS DBs themselves but the (binary)intermediate files created by Pass 1 of a reconfiguration. These are converted into larger,but easily transportable, character files by the TO FORMATTEDFILES command. The filescan then be transferred to the target machine via a communications network or magnetictape and converted back into Pass 1 temporary file format by the FROMFORMATTEDFILES command. For example:

On source machine:

FROM DB MASTER/DESITO FORM /F1 /F2RCFCOPY ALLRECONFIG

On destination machine:

FROM FORM /F1 /F2TO DB MASTER/DESIRECONFIG

3.18 Reconfiguring a Global ProjectWe recommend that you use the SAMEREF option when reconfiguring a Global project. Wealso recommend that there are no users in the database at the primary location whenreconfiguring back to the SAMEREF database.

Databases can only be reconfigured at their primary locations.

Note that when a project database is reconfigured, the database sessions will effectively belost. Thus the ability for Global to send only session changes is lost as well. When the nextupdate occurs between locations, the entire database will be sent via the Global daemon.This can take some time if the database is large.12.03:20

Administrator Command Reference ManualReconfiguration3.19 Reconfiguring Extracts

3.19.1 Outputting Changes OnlyThe default for reconfiguration is that, when reconfiguring an extract, only changes made inthe extract are output. To output all elements, as in normal reconfiguration, the keywordFULL must be added to the RECONFIGURE command line. For example:

RECONFIG FULL

3.19.2 The SAMEREF OptionThe SAMEREF option is always used for extracts. You need not to enter the SAMEREFoption; it is assumed.

This means that you can not reconfigure to DBs of a different DB number.

3.19.3 The SESSIONS OptionThe SESSIONS option is always used for extracts. You need not enter the SESSIONSoption; it is assumed.

3.19.4 Reconfiguring a Single ExtractThe procedure for reconfiguring a single leaf extract is as follows:

1. Reconfigure from the DB to a file.2. REVERT the extract to Session 1.3. MERGE CHANGES to remove the intermediate session.4. Reconfigure from the file to a DB.

An alternative strategy would be to replace Steps 2 and 3 by a DB deletion and a DBcreation.

The procedure is similar for single extracts that own other extracts. The only difference is: The MERGE CHANGES command will leave sessions referred to by child extracts.

Thus, the resultant file will be larger than it would have been had there been no extractchildren.

The alternative approach of deleting and recreating the extract is not possible unless allchild extracts are also deleted and recreated.

The Master DB should be reverted to Session 2 rather than Session 1.

3.19.5 Reconfiguring a Family of ExtractsWhen reconfiguring a whole extract family, the following considerations apply:

The REVERT/MERGE operation must be done bottom-up, to minimise the number ofsessions kept.

Reconfiguring from databases to files must be done top-down. Reconfiguring back from files to databases must also be done top-down, and you must

complete the reconfiguration for the whole extract. For example, if you reconfigure allthree database levels of a three level extract to files but only reconfigure the top two filelevels back to databases, the third database will be corrupted due to thereconfiguration of the other two. For further details, see section 3.19.7 below.12.03:21

Before reconfiguring out from a file, refresh the extract.

Administrator Command Reference ManualReconfiguration Before reconfiguring in from a file, the extract must be refreshed from its parent.

For example, given a simple two-level extract containing TEAMA/MASTER, TEAMA/EXTRACT, the sequence would be:

1. Refresh TEAMA/EXTRACT.2. Reconfigure TEAMA/MASTER to file /A, /B.3. Reconfigure TEAMA/EXTRACT to file /C, /D.4. REVERT TEAMA/EXTRACT to Session 1.5. MERGE CHANGES on TEAMA/EXTRACT.6. REVERT TEAMA/MASTER to Session 2.7. MERGE CHANGES on TEAMA/MASTER.8. Reconfigure from file /A, /B to TEAMA/MASTER.9. Refresh TEAMA/EXTRACT (to pick up changes made in Step 8).10. Reconfigure from file /C, /D to TEAMA/EXTRACT.

3.19.6 The RCFUPDATE CommandWhen the RCFUPDATE command is used on an extract, all affected attributes will beupdated regardless of whether or not the element has been claimed to the extract. Thismeans that, if many extracts of the same extract family are updated, the same changes willbe made to each of the extracts.

3.19.7 Example of Reconfiguring a Three Level ExtractConsider this three-level extract:

All databases must be reconfigured to files first and then reconfigured from the files to thedatabases, in the order; MASTER, EXT, EXTBOT. If this sequence of operations is notcompleted, then databases will be corrupted. For example, if EXTBOT is not reconfiguredfrom file, then EXTBOT will be corrupted as a result of the reconfiguration of the other twodatabases. It is therefore suggested that you make backups of databases beforereconfiguring them.

The sequence of commands to reconfigure the above three level extract could therefore be:

Note: The REFRESH, REVERT and MERGE CHANGES commands have not been shownbelow.

FROM DB CTBATEST/MASTERTO FILE /MASTERA /MASTERBRCFCOPY ALLRECONFIG SESSIONSFROM DB CTBATEST/EXT12.03:22

TO FILE /EXTA /EXTB

Administrator Command Reference ManualReconfigurationRCFCOPY ALLRECONFIG SESSIONSFROM DB CTBATEST/EXTBOTTO FILE /EXTBOTA /EXTBOTBRCFCOPY ALLRECONFIG SESSIONSFROM FILE MASTERA /MASTERBTO DB CTBATEST/MASTERRECONFIGFROM FILE EXTA /EXTBTO DB CTBATEST/EXTRECONFIGFROM FILE EXTBOTA /EXTBOTBTO DB CTBATEST/EXTBOTRECONFIG

It is not necessary for the reconfiguration back from file to be done within the same sessionof RECONFIGURER. For example, in a global project where MASTER, EXT and EXTBOTare primary at different locations, then the following sequence could be followed:

1. At location A (primary location for MASTER):

2. At location B (primary location for EXT):

3. At location C (primary location for EXTBOT):

Steps 1 to 3, reconfiguring from databases to files, can be done in parallel.

4. At location A (primary location for MASTER):

The user must now propagate the whole database to locations (B) and (C).

FROM DB CTBATEST/MASTERTO FILE /MASTERA /MASTERBRCFCOPY ALLRECONFIG SESSIONS

FROM DB CTBATEST/EXTTO FILE /EXTA /EXTBRCFCOPY ALLRECONFIG SESSIONS

FROM DB CTBATEST/EXTBOTTO FILE /EXTBOTA /EXTBOTBRCFCOPY ALLRECONFIG SESSIONS

FROM FILE /MASTERA /MASTERBTO DB CTBATEST/MASTERRECONFIG12.03:23

Administrator Command Reference ManualReconfiguration5. At location B (primary location for EXT)

The user must now propagate the whole database to locations (C) and (A).

6. At location C (primary location for EXTBOT)

The whole database will be propagated to locations (A) and (B) automatically.

Steps 4 to 6, reconfiguring from files to databases, should be done consecutively.

3.19.8 Reconfiguring the Transaction Database in a Global ProjectThe Global Daemon stores most of the commands that it is asked to perform at a location ina transaction database. Each location has its own transaction database. For details, seeTransaction Database.

If a transaction database becomes corrupt, it may be necessary to reconfigure it. Forinformation about this, see Running Global Projects with PDMS.

Note: The daemon for a location must be stopped before reconfiguring its transactiondatabase.

FROM FILE /EXTA /EXTBTO DB CTBATEST/EXTRECONFIG

FROM FILE /EXTBOTA /EXTBOTBTO DB CTBATEST/EXTBOTRECONFIG12.03:24

Administrator Command Reference ManualSystem and Global Projects4 System and Global Projects

This chapter describes how ADMIN elements and their attributes, in a System databasediffer when a Global project is used.

You can navigate to the elements in the System and Global databases, and query theirmembers and attributes in the normal way.

A full list of Elements and their Attributes is included in the Data Model Reference Manual.

Session information is stored separately in the COMMs database; and the MISC databasestores inter-db macros and messages. The communications world element in the COMMsdatabase contains the project lock. This may be set or cleared using LOCK and UNLOCKsyntax.

When you use the MAKE GLOBAL command to make a standard project into a globalproject, the Standard System database is split into two new database files; the Globaldatabase and the (local) System database.

A modified sysvir.dat virgin database is used to upgrade the System database file xxxsys,where xxx is the 3-character project code. The communications world element LCOMW isadded. The glbvir.dat database template file is used to create the Global database filexxxglb.

The existence of the xxxglb database file shows that the project is global.

The following elements are added: The communications world element LCOMW The Global Locations world element GLOCW, which will own GRPLI elements which in

turn own GRP elements The Global Team World element GTMWL The Global Stamp World element GSTWLD. If stamps exist in the System database,

they are all copied to the Global Stamp World element and deleted from the Systemdatabase.

The attributes of these elements and their members, and the changes to other ADMINdatabase elements which occur when a Project is made Global, are described in thefollowing pages.12.04:1

The Global database contains information that is common to all Locations running a Globalproject. The Global database is readable at all locations but is it can only be written to at theHub. Changes to the Global database are propagated to all the other Locations. This meansthat the Global database is the same at every Location, except during the short timechanges are being propagated.

Each local System Database contains project information that is specific to the Location.The local administrator can write to the local system Database. A local System database is

Administrator Command Reference ManualSystem and Global Projectssimilar to the System database in a non-global Project. The main difference is that some ofthe standard ADMIN elements will be redundant. The differences are described below.

Session information is stored separately in the COMMs database; and the MISC databasestores inter-db macros and messages. The Comms and Misc databases are local to eachLocation.

The communications world element in the COMMs database contains the project lock andisolation flags. The project lock may be set or cleared using LOCK and UNLOCK; and theIsolation flag may be set true or false using ISOLATION syntax. Both lock and isolation maybe set or queried remotely by the Hub or an administering location.

4.1 Structure of the Local System Database

The Local System database contains the data for local Fonts, Modules, Users, MDBs, DBSets, Scopes and ACRs: these elements correspond to those that existed in the Systemdatabase of a Standard project. The communications data is held in a new LCOMWLocation Communications world element. The Team World and Role Worlds still exist in thelocal System database, but they are empty. The Team data is stored in the Global TeamWorld element GTMWL in the Global database, and the Role data is stored in the GlobalRole World.

The TEAM and USER elements in the Standard System database cross-reference eachother, that is each team element holds a list USLI of users belonging to the team and eachuser element holds a list TMLI of teams to which the user belongs. In the Global database, aTeam does not maintain a USLI list of users belonging to it.

Note: This means that a report of all Users at every Location in the Project can only beobtained by combining reports from each Location.

The TMLI list in the USER element in the Local System database will continue to provide alist of teams to which a user at a particular location belongs.

In the same way that a TEAM element no longer maintains a list of users in that team, a DBelement in a team does not maintain a list of MDBs to which the DB belongs. The MDBelement, in the Local System database keeps a list of DBs belonging to it.

The detailed changes to the elements and attributes are described below.12.04:2

Administrator Command Reference ManualSystem and Global ProjectsSTAT ElementThis element already exists in the Local System database, but certain attributes have beenrelocated to the Global System database. The attributes are the same as in a StandardProject with the addition of:

Note: When a location is created, the LOCRF attribute in its local system DB will be set tothe reference of its LOC location element in the global system database.

LCOMW ElementThe Location Communications World element LCOMW is called /*LC. It contains elementsthat describe the communications between one Location and all the other Locations withwhich it can communicate. The LCOMW element owns a LCOMC element, LCOMLelements and LCTIML elements.

LCOMC ElementThe LCOMC element contains general details about the configuration of the Admin daemonat the current location. There should be only one LCOMC element in the database.

Attributes:

LCOML ElementThe LCOML element contains a list of LCOMD elements, each of which specifies detailsabout the communications link between the current site and one other site, as describedbelow.

Attributes:

Locrf text(120) 120 character text:current Location Reference

Name /name

Lock false

Owner /*LC

Logfn /filenam Log file name

Logms false

Loglv 0 Diagnostic level

Name /name

Type LCOML

Lock false

Owner /*LC12.04:3

Administrator Command Reference ManualSystem and Global ProjectsLCOMD ElementThe LCOMD element contains specific details about the communications link between thecurrent site and one other site, and controls scheduled updates. There will be one LCOMDelement for each location, which has a communications link with the current location.

Attributes:

The Timer values are:

For example:

Name /name

Lock false

Owner /name

Description unset 120 character text

Locrf /name Name of Location which has comms link with currentLocation

Timer frequency of update events 120 character text:(See below)

Times 0 Time window start

Timee 2400 Time window end

Timei 30 Interval in seconds between communication attempts

Timeo 10 Number of re-tries

Execb unset 120 character text: name of script to be run beforeupdates are transferred (optional)

Execa unset 120 character text: name of script to be run afterupdates are transferred (optional)

LNoUpd false If set TRUE, the scheduled update is disabled. Thisis useful during certain house-keeping operationssuch as merging.

Minutes past the hour 0 - 59

Hours 0 - 23

Days 1 - 31

Months 1 - 12

Days of the week 0 (Sunday) - 6

Timer '0,30 * * * *' specifies every half hour, every day.

Timer '12 10,12,14,16,18 * * 1,5 ' specifies 12 minutes past the hours given, Mondayto Friday.12.04:4

Administrator Command Reference ManualSystem and Global ProjectsThe attributes TIMES and TIMEE are not implemented at this release.

Files such as Isodraft external plot files are not propagated automatically by the globaldaemon. However, there is a mechanism in the daemon to allow such files to be transferredto and from neighbouring locations, during scheduled updates (or the UPDATE ALLcommand). The directory to receive transferred files is defined by the environment variable%IMPORT%. Each location to which files are to be transferred requires its own transferdirectory - %EXP_ABC% for location ABC. Transfer of other data is described more fully inthe Global User Guide.

Offline locations: Note that transfer of such files to or from offline locations must be donemanually.

LCTIML ElementThe LCTIML element is present in a Global project only and has the following functions:

It overrides the default transaction event timings. It contains a LEVENL attribute, which sets the time interval for the event loop for all

locations, in seconds. It contains attributes that control the frequency of automatic merges on the transaction

database. It contains a list of LCTIMD elements, each of which specifies details about the event

timings between the current site and one other site, as described below.

Attributes:

At times specified by LMERTI, the transaction database will automatically be merged andcommands deleted as specified by the LMERSU and LMERFA attributes. The LMERDLattribute must be set to true. For example, the automerge data could be set as follows:

LMerti 59 23 * * 3,6 LMersu 10 Lmerfa -1 Lmerdl true

In this example, the daemon would delete all successful commands older than 10 days andmerge the transaction database. Failed commands would not be deleted.

Note: If both LMERSU and LMERFA are set to -1, then the transaction database will not bemerged.

Levenl 5 Time interval for event loop (secs)

Lmerti Frequency of Automerges. 120 character text:

(settings as for Timer above)

Lmersu 3 Time in days after which successful commandsshould be deleted. The value -1 means no deletion.

Lmerfa 3 Time in days after which failed commands should bedeleted. The value -1 means no deletion.

Lmerdl false If true, transaction database is merged and purged atspecified times.12.04:5

Administrator Command Reference ManualSystem and Global ProjectsLCTIMD ElementThe LCTIMD element contains details about the event timings between the current site andone other site. There will be one LCTIMD element for each location that communicates withthe current location.

Attributes.

4.2 Structure of the Global DatabaseThe Global System database contains Teams, Databases, Roles, Locations and Stamps.Figure 4:1.: Structure of the Global System Database shows the structure of the GlobalSystem database.

Figure 4:1. Structure of the Global System Database

Name /name

Description unset 120 character text

Locrf /name Reference to Location communicating with currentLocation

Lendti 604800 Command timeout period, in seconds (default is 7 days in seconds)

Lmaxtr 100 Maximum number of retries to send command

Ltimei 120 Time interval between retries, in seconds

WORLDWorld

/*GSGSTAT

Global StatusWorld

LOCLILocation

List

LNKLILinks List

GRPGroups

LNKLinks

LOCLocations

/*GLGLOCWL

Location World

/*GROGROLWGlobal

Role World

ROLERoles

/*GSTGSTWLD

GlobalStampWorld

STAMPStamps

STLSTStamp

List

GRPLIGroup List

/*GTGTMWLGlobal

Team World

TEAMTeams

DBDBs

DBLIDB List

DBLOC

PEROPPerops12.04:6

Administrator Command Reference ManualSystem and Global ProjectsGSTAT Element (GSTAT)Only one /*GS element can exist in the database and it is inherited from the STAT elementin the Standard System Database.

Attributes

GTMWL ElementThe Global Team World element GTMWL is named /*GT. Only one /*GT element can exist inthe database. It is the same as the TMWL element, except that:

It does not own a user list element USLI. The DB element does not own an MDB list element MDBL. The DB element owns a single DBLOC element DBLOC.

Attributes

TEAM Element

Attributes

Name /*GS

Lock false

Owner /*

Prjnumber unset Project number: 17 character text

Maxusers 999999

Prjdesc unset Project description 120 character text

Charset -370086

Hccnt Extract list changes count Integer =< 999999

Naccnt Non additive changes count

Clccnt Change list changes count

Name /*GT

Lock false

O