Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Disclaimer
Information of a technical nature, and particulars of the product and its use, is given by AVEVA Solutions Ltd and its subsidiaries without warranty. AVEVA Solutions Ltd and its subsidiaries disclaim any and all warranties and conditions, expressed or implied, to the fullest extent permitted by law. Neither the author nor AVEVA Solutions Ltd, or any of its subsidiaries, shall be liable to any person or entity for any actions, claims, loss or damage arising from the use or possession of any information, particulars, or errors in this publication, or any incorrect use of the product, whatsoever.
Copyright
Copyright and all other intellectual property rights in this manual and the associated software, and every part of it (including source code, object code, any data contained in it, the manual and any other documentation supplied with it) belongs to AVEVA Solutions Ltd or its subsidiaries. All other rights are reserved to AVEVA Solutions Ltd and its subsidiaries. The information contained in this document is commercially sensitive, and shall not be copied, reproduced, stored in a retrieval system, or transmitted without the prior written permission of AVEVA Solutions Ltd Where such permission is granted, it expressly requires that this Disclaimer and Copyright notice is prominently displayed at the beginning of every copy that is made. The manual and associated documentation may not be adapted, reproduced, or copied, in any material or electronic form, without the prior written permission of AVEVA Solutions Ltd. The user may also not reverse engineer, decompile, copy, or adapt the associated software. Neither the whole, nor part of the product described in this publication may be incorporated into any third-party software, product, machine, or system without the prior written permission of AVEVA Solutions Ltd, save as permitted by law. Any such unauthorised action is strictly prohibited, and may give rise to civil liabilities and criminal prosecution. The AVEVA products described in this guide are to be installed and operated strictly in accordance with the terms and conditions of the respective licence agreements, and in accordance with the relevant User Documentation. Unauthorised or unlicensed use of the product is strictly prohibited. First published September 2007 AVEVA Solutions Ltd, and its subsidiaries 2007 AVEVA Solutions Ltd, High Cross, Madingley Road, Cambridge, CB3 0HB, United Kingdom
Trademarks
AVEVA and Tribon are registered trademarks of AVEVA Solutions Ltd or its subsidiaries. Unauthorised use of the AVEVA or Tribon trademarks is strictly forbidden. AVEVA product names are trademarks or registered trademarks of AVEVA Solutions Ltd or its subsidiaries, registered in the UK, Europe and other countries (worldwide). The copyright, trade mark rights, or other intellectual property rights in any other product, its name or logo belongs to its respective owner.
Contents
Page
Administrator Command
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1 How to Use This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
Reconfiguration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
Reconfiguration Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1 Starting up RECONFIGURER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1 Administrative and Querying Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2 Basic Reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2
Reconfiguring a Single Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying the Source Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying the Destination DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying What Will be Copied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting the Reconfiguration Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of a Simple Reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2 3:3 3:4 3:4 3:4 3:5
Using the SAMEREF Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:5 Using the SESSIONS Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:6 Listing the Reference Number Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:7
12.0
Global Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:7 Controlling RECONFIGURER Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:7 Copies and Reconfigured Copies of DBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:8
Copies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:8 Reconfigured Copies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:8
Transferring Data Between Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:13 Upgrading a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:14 Reconfiguration Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:17
Standard Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:17 General Format of Pass 2 Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:18 Codes Used to Identify Message Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:18
Database Transfers between Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:19 Binary and Character Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:20 Transfer Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:20 Reconfiguring a Global Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:20 Reconfiguring Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:21
Outputting Changes Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The SAMEREF Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The SESSIONS Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reconfiguring a Single Extract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reconfiguring a Family of Extracts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The RCFUPDATE Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of Reconfiguring a Three Level Extract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reconfiguring the Transaction Database in a Global Project. . . . . . . . . . . . . . . . . . . . . . . 3:21 3:21 3:21 3:21 3:21 3:22 3:22 3:24
ii
12.0
TRMSGW Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:2 TRYEAR, TRMONT and TRDAY Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:3 TRUSER and TRLOC Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:3 TRINCO element (Input Command) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:3 TROUCO element (Output Command) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:6 TROPER element (Operation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:9 TRMLST, TRSLST, and TRFLST Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:11 TRMESS, TRSUCC, and TRFAIL Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:11
iii
12.0
CDESC (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHANGE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHECK (Data Integrity Checking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHECKOPTION (Data Integrity Checking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CNAME (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . COPY (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CREATE (Project definition). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CURRENT (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DADD (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DEALLOCATE (Global Project Administration - Hub only) . . . . . . . . . . . . . . . . . . . . . DEFER (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DELETE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DREMOVE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DUMP (Reconfiguration). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DUPLICATENAMES (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . EDIT (Module definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ERRORFILE (Data Integrity Checking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ERRORS (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EXCHANGE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EXCLUDE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EXPUNGE (Project Administration). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EXTERNAL (Data Integrity Checking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EXTRACT (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FINISH (General PDMS Command) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FONTDIRECTORY (Font definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FONTFAMILY (Font definition). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FROM (Reconfiguration). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FULL (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GENERATE (Global Project Administration - Hub only) . . . . . . . . . . . . . . . . . . . . . . . GETWORK (General PDMS Command). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HUBLOCATION (Global Project Administration - Hub only) . . . . . . . . . . . . . . . . . . . . INCLUDE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . INITIALISE (Global Project Administration). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ISOLATION (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LIST (Querying) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LOAD (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LOCK (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAKE GLOBAL (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAXERRORS (Data Integrity Checking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAXUSERS (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7:14 7:15 7:18 7:20 7:23 7:24 7:26 7:32 7:33 7:34 7:35 7:36 7:38 7:39 7:40 7:41 7:43 7:43 7:44 7:44 7:45 7:47 7:48 7:50 7:51 7:51 7:54 7:55 7:55 7:56 7:57 7:58 7:58 7:59 7:60 7:62 7:63 7:64 7:64 7:65
iv
12.0
MAXWARNINGS (Data Integrity Checking). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:65 MERGE CHANGES (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:66 MESSAGE (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:68 MODE (Data Integrity Checking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:69 MODULE (Module Definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:70 MOVE (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:71 NEW (Project definition and Global Project Administration). . . . . . . . . . . . . . . . . . . . 7:72 NEW STAMP (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:74 PING (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:75 PREVOWNER (Global Project Administration - Hub only). . . . . . . . . . . . . . . . . . . . . . 7:76 PROJECT (Project definition). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:77 PURGE (Project Administration and Global Project Administration) . . . . . . . . . . . . . 7:79 QUERY (Querying) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:80 RCFCOPY (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:85 RCFUPDATE (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:87 RCFUPGRADE (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:87 RECONFIGURE (Reconfiguration). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:88 RECOVER (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:89 REINIT (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:91 REMOTE (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:92 REMOTEMESSAGE (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . 7:96 REMOVE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:96 RENEW (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:97 REORDER (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:98 REPAIR (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:98 REPLICATE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:99 RESETXREFS (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:101 REVERT (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:102 SAVEWORK (General PDMS Command) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:103 SET (Project definition and Global Project Administration) . . . . . . . . . . . . . . . . . . . 7:104 SORTALLOCATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:105 STATISTICS (Data Integrity Checking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:105 STATUSSESSION (Querying) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:106 STOP (Data Integrity Checking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:106 SYNCHRONISE (Global Project Administration). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:107 SYSTAT (Querying) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:108 SYSTEMLOCATION (Global Project Administration - Hub Only) . . . . . . . . . . . . . . . 7:110 TADD (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:111 TERM (General PDMS Command) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:112 TO (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:112
12.0
TRANSFER (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TREMOVE (Project definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TTFONT (TrueType font definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UNLOCK (Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UPDATE (Global Project Administration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UPGRADE (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . USERADD TO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . USERREM/OVE FROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VB (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XREF (Reconfiguration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7:113 7:115 7:115 7:116 7:117 7:119 7:119 7:120 7:120 7:121
vi
12.0
Introduction
This manual describes the PDMS ADMIN commands for Standard (non-global) and Global projects. It is written for System Administrators who are already experienced ADMIN users and who wish to write macros or use command input, rather than the GUI. The content of this manual is based on the assumption that you are already familiar with the concepts that a PDMS System Administrator needs to understand. If you are not familiar with these concepts, you should refer to the relevant user guide, as follows: Using PDMS ADMIN for a standard (non-global) project is described in the AVEVA ADMIN User Guide, which tells you how to set up and administer PDMS projects using the GUI. The User Guide also describes the concepts that PDMS System Administrators need to understand. Using Plant Design Global via the GUI is described in the Global User Guide, which also describes the concepts in Plant Design Global that PDMS System Administrators need to understand.
Within the manual, commands that are only available in AVEVA Global are labelled as Global Project Administration Commands. Some of these commands are only available at the Hub of a Global Project, and this is also shown. Some options in standard commands are only available in Global Projects and these options are also indicated by 'Global' in associated text. This manual also describes how to use DICE, the PDMS Data Integrity Checker, outside PDMS, as there is no GUI for the stand-alone module. It also describes database reconfiguration, which is also a command line or macro operation.
1.1
Macros
Most people who read this manual will be writing macros, either to run into PDMS when required, for example, to create a new project, or as part of customising the ADMIN interface. 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 the REPLICATE command to create a macro which will replicate a project. For information about writing more complicated macros using the PDMS Programmable Macro Language, (PML), see the Software Customisation Guide and the Software Customisation Reference Manual.
1.2
1:1
12.0
Command Reference manual as there is no interface to stand-alone DICE, and you will need to enter commands interactively or via a macro. Reconfiguration, applies to Standard and Global projects and describes database reconfiguration. System and Global Projects, applies to Standard and Global projects. It contains maps of the System Database and Global Database Hierarchies, and a list of the ADMIN elements and their attributes that can be set explicitly by the user. Transaction Database applies to Global projects only, and describes the transaction database, the elements in it, and their attributes. Command Summary applies to Standard and Global projects. It lists the ADMIN commands in functional groups. Command Details, applies to Standard and Global projects. It occupies the majority of the manual and describes every ADMIN command. The descriptions appear in alphabetical order of command names. Drawing File Name and Folders file name conventions used for Drawing and Picture files during propagation.
1:2
12.0
Stand-Alone DICE
The PDMS Data Integrity Checker (DICE)PDMS can be run as a stand-alone program outside PDMS. This may be necessary if the System database has been corrupted, and you cannot enter PDMS. Stand-alone DICE is started up using the script named dop, supplied in the PDMSEXE directory. Give the following command, outside PDMS:
$PDMSEXE/dop
For a summary of the commands that you can use in DICE, see the Data Integrity Checking commands in Command Summary. Commands to exit from DICE in stand-alone mode are:
STOP FINISH
You can send the reports generated by DICE to a named file in your working directory using the ALPHA command.
2.1
DICE Errors
PDMS obtains the text of all its user messages from an external file. When DICE is used from within a PDMS project, this file is automatically available, but this is not the case in stand-alone mode. Hence the next command you must give in stand-alone mode is the ERRORFILE command, followed by the name of the error message file. For example:
ERRORFILE /%PDMSEXE%/MESSAGE.DAT
Note: 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 current version of makmac.mac, the project configuration macro.
2.2
DICE Commands
Set up the options you require using the following commands (see the appropriate command pages for details): ERRORFILE MODE MAXERRORS MAXWARNINGS STATISTICS
2:1
12.0
You 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 can only refer to databases by their external filenames rather than by their internal PDMS DB names. Up to ten files may be specified in a single command. Note: The EXTERNAL command cannot be used in stand-alone mode (or by REMOTE CHECK), because only one DB file can be accessed at a time.
2:2
12.0
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 appreciate the steps involved, it is helpful to have some knowledge of PDMS database structures and their management. For a summary of this information, including an explanation of DDLs (Database Description Languages) and DABACON (the DAtaBAse CONtrol program), read the chapter The PDMS Database Management System in the ADMIN User Guide.
3.1
Reconfiguration Process
Reconfiguration is a two-pass operation, acting on either a complete database or on specified parts of one. In the first pass, RECONFIGURER scans a named source database and copies the data for 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 specified destination 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 both compact and uncorrupted. The reference and non-reference attributes of the elements are held in different intermediate files. The method of transfer of data to the destination database ensures that all referencing is complete and consistent. The source and destination databases may have different DDLs. This enables existing data to be restructured to conform to a new database structure and so, for example, to be used with a new version of PDMS. Reconfiguration can used to transfer a project to different hardware. The intermediate files 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 in this case the intermediate files need not be decoded.
3.2
Starting up RECONFIGURER
Enter PDMS in non-graphics (tty) mode by typing:
pdms tty
Then specify the Project and User ID/Password, and enter ADMIN. For example:
3:1
12.0
3.3
FILENAME /
Lists all DBs which are copies of the specified DB. For example:
3.4
3.4.1
Basic Reconfiguration
Reconfiguring a Single Database
The simplest reconfiguration involves a single DB which has no references into it from other DBs; 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 has been completed, the source DB will remain unchanged, and the destination DB will contain a compacted copy of the parts of the source which were specified in the copy list.
3:2
12.0
The transfer of data takes place in two passes, the second of which is further divided into two phases: PASS 1 The data is read from the source DB and written to a pair of intermediate files. The first file holds the element structures and the non-reference attributes, the other holds the reference attributes. The first file is read by RECONFIGURER and used to recreate the original structures in the destination DB, including setting of the non-reference attributes. The second intermediate file is read and its contents used to set all reference attributes in the destination DB and to perform insertion operations.
PASS 2 - Phase 1
PASS 2 - Phase 2
The reason for the two phases is that references in the source DB may refer to elements lower down in the hierarchy. It is necessary, therefore, to create all elements in the destination DB before trying to set references to any of them. Since the two passes perform independent and consecutive operations, the process can be interrupted 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
FROM DB STEELS/STEELS
Source data is in database STEELS/STEELS in current project
3:3
12.0
3.4.3
TO DB STEELS/STEELS
Reconfigured data to go to database STEELS/STEELS in current project
TO DBFILE /des008
Reconfigured data to go to specified file (assumes project directory is current directory) 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 same type as the source DB, and will normally be empty, but need be. For an explanation of what happens 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 is the most common option for the general compaction of DBs. It is explained further in Copies and Reconfigured Copies of DBs. Note: The new database will need to be added to the appropriate MDBs.
3.4.4
RCFCOPY ALL
The RCFCOPY ALL command copies all elements in the list part of the World element of the source DB into the World element of the destination DB. World itself is not copied. Parts of a database can be copied by using the RCFCOPY command followed by the name of the element 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 RCFCOPY command becomes the copy list. Note that you must use RCFCOPY ALL if you intend to use the RECONFIGURE SESSIONS command at the next step, as the SESSIONS option is not valid if you only carry out partial reconfiguration.
3.4.5
3:4
12.0
extent of information output is deleted, ready for another reconfiguration operation if required. 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 ALPHA FILE 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
*** 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 Completed 0 Elements were not defined in DDL 0 Elements have been lost 0 Elements are no longer named 0 Attributes were incorrectly defined 0 Elements were not inserted.
See Reconfiguration Messages, for a complete list of output messages.
3.5
3:5
12.0
the same reference numbers are maintained after reconfiguration, you can use the command:
RECONFIGURE SAMEREF
In this case the destination DB number must be the same as the original one. This means that you will have to delete the source database, and create a new one with the same number. The following example illustrates the use of the SAMEREF option:
FROM DB MASTER/DESIGN TO FILE /F1 /F2 RCFCOPY ALL RECONFIGURE DELETE DB MASTER/DESIGN CREATE DB MASTER/DESIGN DESI DBNO nn FROM FILE /F1/F2 TO DB MASTER/DESIGN RECONFIG SAMEREF
3.6
RECONFIGURE SESSIONS
The option is not valid for SYSTEM, or GLOBAL DBs, and is not available for a partial reconfiguration. The following example illustrates the use of the SESSIONS option:
3:6
12.0
3.7
Q NEWREF refno
where refno is the new reference number. The old reference number will be returned. For example:
Q NEWREF #32/202
=42/205
3.8
Global Projects
In a Global project, you can reconfigure the System and Global databases. The commands are:
3.9
VB BRIEF FULL
Very brief output mode Brief output mode Full output mode
In VB (Very Brief) mode, a message is output as each element in the copy list is successfully created. If the copy command was RCFCOPY ALL, then a message is output for each element successfully copied into the World of the destination DB.
3:7
12.0
In BRIEF mode, all information output in VB mode is given, plus messages describing any errors that have occurred due to DDL changes. In FULL mode, all information output in BRIEF mode is given, plus a log of all elements successfully created and named. Note that FULL mode is very verbose and its use is not generally recommended. The default is BRIEF mode. An upper limit may be set on the number of errors that are acceptable during Pass 2 of a reconfiguration using the ERRORS command. For example:
ERRORS 50
If 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 situation may be reset if necessary by using the ERRORS command followed by a negative value. For example:
ERRORS
-1
3.10
3.10.1
Copies
A copy of a DB can be made by using the RCFCOPY command. For example the following command: will create a copy of the existing DB PIPEA/PIPEA in the new DB ADMIN/TEST.
There is no implied direction of copying. Thus, in the previous example, PIPEA/PIPEA and 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 Copies
A reconfigured copy is one named by the TO DB or TO NEW commands. The key features of reconfigured copies are: A reconfigured copy has a different DB number from that of the source DB.
3:8
12.0
In the reconfiguration process, the destination DB becomes a reconfigured copy of the source 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 Reconfiguration
The previous sections in this chapter describe how a single DB can be reconfigured. In a real PDMS project, with many DBs of different types and with reference attributes pointing from 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. It also 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
Branch /150-B1
Similarly, references can exist from Design DBs into Catalogue DBs (the SPREF attribute of a piping component pointing to an SPCOM, for example), but references cannot exist from a Catalogue DB back into a Design DB. When a DB is reconfigured without the SAMEREF option, most of the reference numbers of its 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 scanned and the reference or reference array attributes are changed to point to the correct element once more. For example, assume that the reference number of an SPCOM in a Catalogue DB changes from =17/3108 in the original DB to =49/2014 in the reconfigured copy. All piping components whose SPREF attribute was previously set to =17/3108 must have SPREF reset to =49/2014. Such components might exist in several DBs. Reference resetting is performed by the RCFUPDATE command described in the next section.
3:9
12.0
3.11.2
RCFUPDATE DB MASTER/DESIGN
Updates references to the reconfigured DB from DB MASTER/DESIGN.
Thus, giving the RCFUPDATE command twice results in the reference =123/456 being reset to =123/458.
RECONFIGURER knows which types of DB can be pointed to by reference attributes in other types of DB, and so does not attempt to update DBs which could not possibly point to the latest reconfigured copy. A report is output which lists which DBs were and which were not updated.
The table of references is maintained across multiple reconfigurations, as long as you do not exit from ADMIN.
3:10
12.0
3.11.3
LOAD /DUMP1 FROM DB MASTER/DESIGN TO DB MASTER/DESNEW RCFCOPY ALL RECONFIGURE DUMP /DUMP2
These commands will read an existing reference number index from file /DUMP1, add the reference number pairs from the specified reconfiguration to it, and then write the index out again to the file /DUMP2. If a number of databases have been reconfigured, the dump file will record the crossreference index for all of them. The LOAD command replaces the current index. The command LOAD APPEND appends the table to the current index.
3.11.4
BLTA GPWL
CASW LIBY
CATA MATW
CCTA RUNW
CMPW SITE
CONW SPWL
When a root element is copied, all elements owned by it are also copied. A maximum of 300 root elements may be specified in a single copy list. The selective commands RCFCOPY CATALOGUE and RCFCOPY SPECIFICATIONS cause the first root elements of type CATA and SPWL, respectively, to be copied from the list 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 or reference number) in a RCFCOPY command. For example:
3:11
12.0
If you are not at a top level element, there must be an existing element in the destination DB into whose list part you wish to incorporate the element being copied. This is done using the INTO option of the RCFCOPY command. For example:
Several RCFCOPY commands can be given in sequence to add elements to the copy list. For example, the sequence
RCFCOPY /SITE3
Note: Partial reconfiguration of PADD DBs is only allowed for picture elements (i.e. SHEE, BACK, OVER, SYLB, LALB) and above.
3:12
12.0
To update the references of the original database to point to the new copied elements use the RCFUPDATE INTERNAL command described in Updating References into a Reconfigured Database.
3.11.5
Copying Groups
If a Group World is specified in a RCFCOPY command, only the Group World and its owned Groups are copied. Errors will occur in Phase 2 if the Group members have not be copied as well. It is meaningless to try to reconfigure a group on its own.
3.12
FROM DB /CATOLD
Specify source DB.
TO DB /CATNEW
pass 2 of reconfiguration to be done.
3:13
12.0
Note: 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 attributes point outside the set of DBs being transferred, an extension of the same procedure could be used. Consider the transfer of the whole of one Design DB, the whole of a Catalogue DB and one item of equipment from a second Design DB, thus: Source DB CIVIL/STRUC4 ANSI/MASCAT SITE-A Elements Transferred Whole Design DB Whole Catalogue DB One Site Destination DB STEEL/MAIN CATAL/MAIN EQUIP/MAIN
The reconfiguration commands should be given in the following order: In the source project:
FROM DB ANSI/MASCAT TO FILES /REC1A /REC1B RCFCOPY ALL RECONFIGURE FROM DB CIVIL/STRUC4 TO FILES /REC2A /REC2B RCFCOPY ALL RECONFIGURE FROM DB VESSEL/V25CT TO FILES /REC3A /REC3B RCFCOPY /SITE-A RECONFIGURE
and in the destination project:
FROM FILES /REC1A /REC1B TO DB CATAL/MAIN RECONFIGURE FROM FILES /REC2A /REC2B TO DB STEEL/MAIN RECONFIGURE FROM FILES /REC3A /REC3B TO DB EQUIP/MAIN RECONFIGURE RCFUPDATE DB STEEL/MAIN RCFUPDATE DB EQUIP/MAIN
Creates Catalogue DB
Creates Design DB
3.13
Upgrading a Project
The XREF and RESETXREFS commands described in this section are intended for use during the upgrading of a project from one version of PDMS to the next. They operate on the
3:14
12.0
data during its transfer from the source DB to the destination DB such that the data can be modified to conform to the requirements of a new DDL. The commands are used to ensure that all cross-references are correctly set after a multiDB reconfiguration. They are particularly useful in the case where two databases of the same 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 DB number, it is best to use XREF and RESETXREFS. These commands are normally handled automatically by the upgrade macros supplied with a new version of PDMS. They may be used independently of the upgrade macros by the experienced user, preferably after consultation with AVEVA Solutions Ltd, and it is for this reason that they are described here. XREF may be used to generate a list of the reference numbers of all elements which need updating for each DB. The list is created during the restructuring of the new DBs in Phase 2 of Pass 2. This list is then used to monitor a partial updating operation, which ensures that all references 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 the RCFUPDATE DB command. The RESETXREFS function applies only to elements whose reference numbers appear in the corresponding XREF file. For example:
3:15
12.0
TO DB XX/A2 FROM DB XX/A1 XREF /XX1 RCFCOPY ALL RECONFIG : : TO DB XX/B2 FROM DB XX/B2 RCFCOPY ALL RECONFIG RESET WITH /XX1 RESOLVE DB XX/A2
A more general command sequence for a project upgrade is shown in the following input and output macros: Input macro
Write Upgrading project CJB Write From PDMS10 to PDMS11 Write Input phase $R6 Checkddl is 11 To db STANA/SAPROP From files /REC1A /REC1B Xref /REC1X Reconfigure To db DEREKF/DFPROP From files /REC2A /REC2B Xref /REC2X Reconfigure To db ALANC/ACPROP From files /REC3A /REC3B Xref /REC3X Reconfigure To db TAMH/THPROP From files /REC4A /REC4B Xref /REC4X Reconfigure To db TAMH/PROP_ATEST From files /REC5A /REC5B Xref /REC5X Reconfigure Reset with /REC1X Resolve db STANA/SAPROP Reset with /REC2X Resolve db DEREKF/DFPROP Reset with /REC3X Resolve db ALANC/ACPROP Reset with /REC4X Resolve db TAMH/THPROP Reset with /REC5X Resolve db TAMH/PROP_ATEST Finish
3:16
12.0
Output macro
Write Upgrading project CJB Write From PDMS10 to PDMS11 Write Output phase $R6 UPGRADE ON From db STANA/SAPROP To files /REC1A /REC1B Copy all Reconfigure From db DEREKF/DFPROP To files /REC2A /REC2B Copy all Reconfigure From db ALANC/ACPROP To files /REC3A /REC3B Copy all Reconfigure From db TAMH/THPROP To files /REC4A /REC4B Copy all Reconfigure From db TAMH/PROP_ATEST To files /REC5A /REC5B Copy all Reconfigure
3.14
Reconfiguration Messages
During the various stages of the reconfiguration process, messages will be output. This is particularly so during Pass 2, in which the data from the intermediate files is used to reconstruct the element hierarchy in the destination DB. In the simplest case these messages will just indicate the start and finish of each phase, and confirm that all elements and their attributes were correctly placed. In a more complex case it is probable that a number of error messages will also be output, indicating potential problems in building up an unambiguous structure in the new DB.
3.14.1
*** 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 during Pass 2. This will contain zero values where no problems were found.
3:17
12.0
The format of this report is: Integer Integer Interger Integer Interger Elements were not defined in the DDL Elements have been lost Elements are no longer named Attributes where incorrectly defined Elements were not inserted
3.14.2
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: CODE: TYPE: OLDREF NEWREF: Identifies the nature of a message arising from the creation or naming of an element. The codes used are detailed in the next section. The type of element, e.g. SITE, BRAN, SHEE etc. The reference number of the element in the source DB (starting with #). The reference number of the corresponding element created in the destination DB (starting with =). This will be blank if the element could not be created. The name given to the element. This applies only if the message is coded EN to indicate that the element has been named (see next section).
NAME:
3.14.3
The remaining characters, which give more explicit meaning to the message, are explained in the following subsections.
3:18
12.0
EC EN
These are output as the reconfiguration proceeds and each message ends with the name of the copied element. Error Messages Relating to Elements (prefix: asterisk)
*ENID
The element could not, therefore, be created. This can occur when the element type is not permitted in the list part of the element above it in the DB hierarchy, for example, if an attempt is made to reconfigure FROM FILES into a DB of the wrong type.
*ENI
An attempt was made to insert the element into a list where it is no longer permitted.
*EL
Element Lost
Elements in the list part of ones that cannot be created are lost, since they cannot be created either. Error Messages Relating to Attributes (prefix: hash sign) These all begin with
#EAE
followed by one or more other messages giving more information about the error.
3.15
3:19
12.0
3.16
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 character files and vice versa.
3.17
Transfer Process
The 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 files can then be transferred to the target machine via a communications network or magnetic tape and converted back into Pass 1 temporary file format by the FROM FORMATTEDFILES command. For example: On source machine:
3.18
3:20
12.0
3.19
3.19.1
Reconfiguring Extracts
Outputting Changes Only
The default for reconfiguration is that, when reconfiguring an extract, only changes made in the extract are output. To output all elements, as in normal reconfiguration, the keyword FULL must be added to the RECONFIGURE command line. For example:
RECONFIG FULL
3.19.2
3.19.3
3.19.4
3.19.5
3:21
12.0
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
3.19.7
All databases must be reconfigured to files first and then reconfigured from the files to the databases, in the order; MASTER, EXT, EXTBOT. If this sequence of operations is not completed, then databases will be corrupted. For example, if EXTBOT is not reconfigured from file, then EXTBOT will be corrupted as a result of the reconfiguration of the other two databases. It is therefore suggested that you make backups of databases before reconfiguring 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 shown below.
FROM DB CTBATEST/MASTER TO FILE /MASTERA /MASTERB RCFCOPY ALL RECONFIG SESSIONS FROM DB CTBATEST/EXT TO FILE /EXTA /EXTB
3:22
12.0
RCFCOPY ALL RECONFIG SESSIONS FROM DB CTBATEST/EXTBOT TO FILE /EXTBOTA /EXTBOTB RCFCOPY ALL RECONFIG SESSIONS FROM FILE MASTERA /MASTERB TO DB CTBATEST/MASTER RECONFIG FROM FILE EXTA /EXTB TO DB CTBATEST/EXT RECONFIG FROM FILE EXTBOTA /EXTBOTB TO DB CTBATEST/EXTBOT RECONFIG
It is not necessary for the reconfiguration back from file to be done within the same session of RECONFIGURER. For example, in a global project where MASTER, EXT and EXTBOT are primary at different locations, then the following sequence could be followed: 1. At location A (primary location for MASTER):
3:23
12.0
3.19.8
3:24
12.0
The attributes of these elements and their members, and the changes to other ADMIN database elements which occur when a Project is made Global, are described in the following pages. The Global database contains information that is common to all Locations running a Global project. The Global database is readable at all locations but is it can only be written to at the Hub. Changes to the Global database are propagated to all the other Locations. This means that the Global database is the same at every Location, except during the short time changes 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
4:1
12.0
similar to the System database in a non-global Project. The main difference is that some of the standard ADMIN elements will be redundant. The differences are described below. Session information is stored separately in the COMMs database; and the MISC database stores inter-db macros and messages. The Comms and Misc databases are local to each Location. The communications world element in the COMMs database contains the project lock and isolation flags. The project lock may be set or cleared using LOCK and UNLOCK; and the Isolation flag may be set true or false using ISOLATION syntax. Both lock and isolation may be set or queried remotely by the Hub or an administering location.
4.1
The Local System database contains the data for local Fonts, Modules, Users, MDBs, DB Sets, Scopes and ACRs: these elements correspond to those that existed in the System database of a Standard project. The communications data is held in a new LCOMW Location Communications world element. The Team World and Role Worlds still exist in the local System database, but they are empty. The Team data is stored in the Global Team World element GTMWL in the Global database, and the Role data is stored in the Global Role World. The TEAM and USER elements in the Standard System database cross-reference each other, that is each team element holds a list USLI of users belonging to the team and each user element holds a list TMLI of teams to which the user belongs. In the Global database, a Team 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 be obtained by combining reports from each Location. The TMLI list in the USER element in the Local System database will continue to provide a list 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 DB element in a team does not maintain a list of MDBs to which the DB belongs. The MDB element, in the Local System database keeps a list of DBs belonging to it. The detailed changes to the elements and attributes are described below.
4:2
12.0
STAT Element
This element already exists in the Local System database, but certain attributes have been relocated to the Global System database. The attributes are the same as in a Standard Project with the addition of: Locrf text(120) 120 character text: current Location Reference
Note: When a location is created, the LOCRF attribute in its local system DB will be set to the reference of its LOC location element in the global system database.
LCOMW Element
The Location Communications World element LCOMW is called /*LC. It contains elements that describe the communications between one Location and all the other Locations with which it can communicate. The LCOMW element owns a LCOMC element, LCOML elements and LCTIML elements.
LCOMC Element
The LCOMC element contains general details about the configuration of the Admin daemon at the current location. There should be only one LCOMC element in the database. Attributes: Name Lock Owner Logfn Logms Loglv /name false /*LC /filenam false 0 Diagnostic level Log file name
LCOML Element
The LCOML element contains a list of LCOMD elements, each of which specifies details about the communications link between the current site and one other site, as described below. Attributes: Name Type Lock Owner /name LCOML false /*LC
4:3
12.0
LCOMD Element
The LCOMD element contains specific details about the communications link between the current site and one other site, and controls scheduled updates. There will be one LCOMD element for each location, which has a communications link with the current location. Attributes: Name Lock Owner Description Locrf Timer Times Timee Timei Timeo Execb Execa LNoUpd 0 2400 30 10 unset unset false /name false /name unset /name 120 character text Name of Location which has comms link with current Location frequency of update events 120 character text: (See below) Time window start Time window end Interval in seconds between communication attempts Number of re-tries 120 character text: name of script to be run before updates are transferred (optional) 120 character text: name of script to be run after updates are transferred (optional) If set TRUE, the scheduled update is disabled. This is useful during certain house-keeping operations such as merging.
The Timer values are: Minutes past the hour Hours Days Months Days of the week For example: Timer '0,30 * * * *' Timer '12 10,12,14,16,18 * * 1,5 ' specifies every half hour, every day. specifies 12 minutes past the hours given, Monday to Friday. 0 - 59 0 - 23 1 - 31 1 - 12 0 (Sunday) - 6
4:4
12.0
The attributes TIMES and TIMEE are not implemented at this release. Files such as Isodraft external plot files files are not propagated automatically by the global daemon. However, there is a mechanism in the daemon to allow such files to be transferred to and from neighbouring locations, during scheduled updates (or the UPDATE ALL command). 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 transfer directory - %EXP_ABC% for location ABC. Transfer of other data is described more fully in the Global User Guide. Offline locations: Note that transfer of such files to or from offline locations must be done manually.
LCTIML Element
The 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.
(settings as for Timer above) Lmersu Lmerfa Lmerdl 3 3 false Time in days after which successful commands should be deleted. The value -1 means no deletion. Time in days after which failed commands should be deleted. The value -1 means no deletion. If true, transaction database is merged and purged at specified times.
At times specified by LMERTI, the transaction database will automatically be merged and commands deleted as specified by the LMERSU and LMERFA attributes. The LMERDL attribute 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 and merge 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 be merged.
4:5
12.0
LCTIMD Element
The LCTIMD element contains details about the event timings between the current site and one other site. There will be one LCTIMD element for each location that communicates with the current location. Attributes. Name Description Locrf Lendti Lmaxtr Ltimei /name unset /name 604800 100 120 120 character text Reference to Location communicating with current Location Command timeout period, in seconds (default is 7 days in seconds) Maximum number of retries to send command Time interval between retries, in seconds
4.2
ROLE Roles GRPLI Group List LOCLI Location List LNKLI Links List PEROP Perops LNK Links
TEAM Teams
DBLI DB List
GRP Groups
LOC Locations
DB DBs
DBLOC
Figure 4:1.
4:6
12.0
GTMWL Element
The Global Team World element GTMWL is named /*GT. Only one /*GT element can exist in the 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.
TEAM Element
Attributes Name Lock Owner Description /name false /*GT unset
4:7
12.0
DB Element
The DB element owns the list element DBLOC which holds four additional attributes (see DBLOC Element). These attributes are attached to the DBLOC element to facilitate separate claiming of both this element and the owning DB element. This scheme reduces the contention between the PDMS ADMIN module and the Global daemon. Attributes Name Type Lock Owner Stype Fino Area Daccess Claimdb Description Proj Fcpyref Bcpyref Extractno Variant Controlled DBLC PRMLOC ISDRDB /name DB false /name DESI n 0 Update Explicit or Implicit if Daccess is Multiwrite unset unset Nulref Nulref n false false List of locations to which DB is allocated Primary Location Does DB have drawing files (except for Foreign DBs, where it is set to the project code) File number Area number
4:8
12.0
DBLOC Element
Attributes Name Type Lock Owner Locrf Prvrf /name DBLOC false /name /name DB element Name of Primary Location Name of previous Primary Location (normally unset) Propg Picfd DEALDB Hccnt Naccnt Clccnt true false Propagation flag Picture file propagation flag
Ref Array Indicates locations where db is being de-allocated Extract list changes count = <999999 Non additive changes count Changes list changes count
4:9
12.0
GLOCWL Element
The Global Location World element GLOCWL specifies information about Locations, Groups and Communications (Links). It is named /*GL and only one /*GL element can exist in the database. The GLOCWL element consists of the three list elements GRPLI for groups, LOCLI for locations and LNKLI for links. It has the following attributes: Attributes Name Lock Owner Aduuid Hubrf Prvrf /*GL false /* text /name Nulref Daemon version string (Project UUID) Hub Location Reference Previous Hub Reference (normally unset)
4:10
12.0
NxtHb Newuid
Nulref text
Next Hub location (normally unset) gets new UUID value to use when setting ADUUID. To be used when a Global project is copied directly without the REPLICATE command (see REPLICATE (Project definition)) having been used.
GRPLI Element
The GRPLI element contains a list of Group elements GRP. A Group is a fully connected local network of Locations which conceptually form a single node in the Plant Design Globaltree structure of Locations. Attributes Name Lock Owner /name false /*GL
GRP Element
The characteristics of each group are defined by a GRP element which has the following attributes: Attributes Name Lock Owner Description /name false /name unset
Membership of a group is indicated by the attribute GRPRF in each location element LOC, as described below. The location elements LOC are themselves listed in the LOCLI element.LOCLI Element The LOCLI element contains a list of all Location elements LOC, including offline Locations and those which belong to Groups. Attributes Name Lock Owner /name false /*GL
LOC Element
The characteristics of each Location are defined by a LOC element which has a set of attributes and a secondary list element DBALL. The DBALL element is a complete list of all
4:11
12.0
Databases allocated to the Location. It is implemented as a Dabacon secondary list of DB reference numbers which refer to DB elements under the DBLI list element of TEAM elements. Locations which belong to a Group have an attribute GRPRF holding the reference number of the Group. If this attribute is null then the Location does not belong to a group. LOC elements also possess a LOCRF attribute which points to the parent of the Location. This attribute is used to determine paths between Locations in the proposed tree structure for connecting Locations. In a future implementation, based on a more general graph structure, the LOCRF attribute might either be dropped or used for another purpose. A Location is only recognised as fully initialised when the logical attribute LINIT is true. Other attributes of a Location are described in the following table. The LOC element has the following attributes: Attributes Name Lock Owner Description Locid Rhost Iconn /name false /name unset XXX rhost name 1 120 character text 3-letter identifier host name Connection type: 1 = on-line 0 = off-line Initialisation flag Group reference set if Location is added to a Group Parent Location
Linit Grprf Locrf PRMRF PRVRF DEALAL CURLOC ADMLOC PRMLOC DBPRIMARY LOCPRIMARY
Primary location of system Database. If unset, (and PRVRF is unset) the Satellite will be administered locally . Nulref false Old primary location (normally unset) Indicates that ALL DBs are currently being deallocated from this location.
True current Location (available everywhere) Currently administered location (available everywhere). Pirmary location of its system db (ref array) - List of Databases primary at the current location. (ref arrary) - List of Locations primary at the current location.
4:12
12.0
DBALL NoExtCreation
List of Databases allocated to this location. default false If true, disables the creation of extracts by this location. Extract creation must be done by the Hub (or an authorised administering location) If true, database files which are locked by dead users may be overwritten if an update requires an entire file copy.
LCpOvWrite
default false
Note: When a Global Project is created an initial Location element is created with a NAME of /PROJECTHUB and a LOCID of HUB. Its LINIT flag is set to TRUE. Note: Do not allow locked files in the current project to be overwritten during copying by Global updates if other projects are using the current project as a foreign one. This is because database readers in the other projects are valid users even though they are not recorded as users in the current project.
DBALL Element
Attributes Lock Owner false /name
LNKLI Element
The LNKLI element contains a list of link elements LNK which specify the connections between pairs of Locations. Not used at this release. Attributes Name Type Lock Owner /name LNKLI false /*GL
LNK Element
Not used at this release.
4:13
12.0
Attributes Name Description LNKRX LINKRY LINKWV /name unset 120 character text
GSTWLD Element
Any existing stamps in the standard System database are copied to the Global Stamp World element and deleted from the System database.
4:14
12.0
Transaction Database
This chapter is applicable to Global Projects only. The Global Daemon stores most of the commands that it is asked to perform in a transaction database. The System Administrator can use this database to get information about the progress of commands, and investigate why commands have failed. (Use GETWORK to see the latest changes to the transaction database) This chapter describes the structure of the transaction database, and explains the function of the elements within it, and their attributes. Note: To avoid data consistency errors, PDMS changes to the transaction database should not be made whilst the daemon is running. This includes deleting commands (TRINCOs) and merging the database. (Using REMOTE MERGE is OK.)
5.1
5:1
12.0
%TRMSG
%TRYEAR
%TRMONT
%TRDAY
%TRUSER
%TRLOC
%TRINCO
%TROPER
%TROUCO
%TRSLST
%TRFLST
%TRMLST
%TRSUCC
%TRFAIL
%TRSUCC
%TRMESS
%TRFAIL
Figure 5:1.
5.2
TRMSGW Element
The Transaction Message World element is called /*MS. There is only one such element and it contains elements that store the communication between the daemon, PDMS and other daemons. It owns any number of TRYEAR elements. Attributes NAME TRSETL Text /*MS
5:2
12.0
5.3
TRYEARs own TRMONTs, TRMONTs own TRDAYs and TRDAYs own TRUSERs.
5.4
5.5
5:3
12.0
restarted, and is sufficient to generate the operations and output commands necessary to execute the command. Note: Local commands added from PDMS, that is those with TRLOCL True, do not contain successes, failures or messages. Attributes NAME TRCNUM INCSTA COMUID text int int ref Not automatically generated Command number The state of processing of the TRINCO This is the reference of the command that sent this command to the daemon. For commands sent by this or other daemons it is the ref of the TROUCO element at the relevant location. For commands originating from PDMS it will be set to null. Module number through with the USER has issued this command, or GLOBALDAEMON module True if command stored directly by PDMS independent of the Daemon Command string USER entered that generate this command, else null Original Location where user issued the command Ultimate target - destination location where command will be executed. For some commands this is the destination of subsidiary commands to be sent, not this command itself. Previous Location which passed the command on to this location (normally the same as the TRLOC element) Auxiliary location. Often used as a location to send auxiliary commands Location of administrator when being remotely administered, else NULL number of other TRINCOs on which this is dependent (always zero) References of TRINCOs on which it is dependent, (always none) Type of dependencies - on success or failure Date command received and recreated Date sent acknowledgement for command Number of times acknowledgement sent Time to execute command (hence allows a delay) Date command made ready (after EXTIME has been reached)
PRVLOC[3] AUXLOC[3] SYSLOC[3] DEPCOU DEPEND[*] DEPTYP[*] DATECR DATEAK NACKN EXTIME[4] DATERD
text text text int ref log date date int text date
5:4
12.0
DATECM DATERP NREPLY MSTEXT TRPASS DATEND NREPAK USERST TRDBRF TRFINO TREXTN TRAREA TRSTYP TRDBNO TRDACC INARCO INTARG[*] TRCARG[*] TRVISI DESC[256]
date date int text log date int text ref int int int int int int int int text log text
Date command completed Date reply sent with results of command Number of times reply sent text info set on completion (normally only if failed to generate operations) True if command succeeded, false if failed. The command fails if any of its operations fail, or if it fails to generate operations Date all processing of command finished - acknowledgement of command received, or command cancelled. Number of times reply acknowledgement received user cancelling the command of Database DB element file number of DB element extract number of DB element area number of DB element filetype of DB element dbnumber of DB element access type of DB element argument count for intargs (args of the command) (defaulted to zero.) Command arguments (passed around as a Conformant array) Command argument NAME=X/Y Visible or not User description qualifiers space separated. e.g.
5:5
12.0
Values of INCSTA state attribute and order of change RECEIVED ACKNOWLEDGED STALLED The command has been received ready for processing. DATECR is set. An acknowledgement has been sent off by this daemon. DATEAK is set and NACKN incremented. The command has failed to create its operations and state will later return to ACKNOWLEDGED ready for retry, or to TIMEDOUT. The command has reached its execute time and is independent. DATERD is set. The command has been processed, and results obtained. DATECM is set. The daemon has sent the results back to the originating location. DATERP is set and NREPLY incremented. An acknowledgement for the result received from originating location. DATEND is set and NREPAK incremented. The command will not be executed now due to dependency rules. DATEND is set. The command has been cancelled and finished with TRPASS false. DATEND is set. The command has timed out before creating its operations and finished with TRPASS false. DATEND is set.
5.6
5:6
12.0
Attributes NAME TRCNUM OUTSTA COMREF text int int ref Not automatically generated. Command number of command being sent. State of processing of the TROUCO. Ref of the TRINCO of this command stored in the receiving location transaction database. This is NULL until an acknowledgement is received. Original Location where user issued the command. Ultimate target - destination location where command will be executed. For some commands this is the destination of subsidiary commands to be sent, not this command itself. Previous Location which passed the command on to this location (normally the same as the TRLOC element). Auxiliary location. Often used as a location to send auxiliary commands. Location of administrator when being remotely administered, else NULL. Next Target location - this is needed to determine which port to assign the output command to, and which location to send the command. Number of other TROPERs and TROUCOs on which this is dependent. References of TROPERs and TROUCOs on which it is dependent. Type of dependencies - on success or failure. Reference of previous operation which generated this output command as one of its post operations. If no previous operation this is NULL. Date command created by owning input command. Date command is ready to send after dependencies satisfied. Date command sent to destination location. Number of attempts when command was sent. Number of attempts sending command before command fails. Number of seconds delay between attempts at sending. Date when command will fail if sending remains stalled. Date acknowledgement received from destination location Number of times acknowledgement received.
ORILOC[3] DESLOC3]
text text
5:7
12.0
DATERP DATERK NREPLY MSTEXT TRPASS POPCOD DATEND NREPAK USERST TRDBRF TRFINO TREXTN TRAREA TRSTYP TRDBNO TRDACC INARCO INTARG[*] TRCARG[*] TRVISI DESC[256]
date date int text log int date int text ref int int int int int int int int text log text
Date reply with results received from destination location. Date reply acknowledgement sent to destination location Number of times reply received. Text info set on completion (normally only if failed to generate operations). True if command succeeded, false if failed. This is determined from the result received. Code for post operation creation function to be run. If none then zero. Date all processing of command finished all post operations generated, or command cancelled, or command timed out. Number of times reply acknowledgement received. User cancelling the command. Reference for Database DB element. File number of DB element. Extract number of DB element. Area number of DB element. Filetype of DB element. Dbnumber of DB element. Access type of DB element Argument count for intargs (args of the command, defaulted to zero). Command arguments (passed around as a Conformant array) Command argument NAME=X/Y Visible or not User description qualifiers space separated. E.g.
5:8
12.0
Values of OUTSTA state attribute and order of change WAIT READY STALLED SENT The command is waiting until it is independent of any other operation/command. DATECR is set. The command is independent and ready to be sent. DATERD is set. The command could not be sent. State will later return to ACKNOWLEDGED ready for retry, or to TIMEDOUT. The command has been sent acknowledgement. DATESN is incremented. and waits for set, NRETRY an is
ACKNOWLEDGED
An acknowledgement has been received from the destination location. DATEAK is set, NACKN is incremented, CMREF is set. A reply with results has been received from the destination location. DATERP is set, NREPLY is incremented. A reply acknowledgement has been returned to the executing location. DATERK, TRPASS, MSTEXT are set. NREPAK is incremented. Post operations could not be created. State will later return to COMPLETE ready for retry, or to TIMEDOUT. Any required post operations have been generated using the result of this command. DATEND is set. The command will not be executed now due to dependency rules. DATEND is set. The command has been cancelled by owning TRINCO by a user. DATEND is set. The command has had the number of sends exhausted, or maximum time exceeded. DATEND is set.
REPLIED COMPLETE
5.7
5:9
12.0
Attributes NAME TRONUM OPSTAT DEPCOU DEPEND[*] DEPTYP[*] PREOP text int int int ref log ref Not automatically generated. Operation number of operation to execute. Note this is not a command number. State of processing of the TROPER: Number of other TROPERs and TROUCOs on which this is dependent. References of TROPERs and TROUCOs on which it is dependent. Type of dependencies - on success or failure. Reference of previous operation which generated this output command as one of its post operations. In none then NULL. Date operation created by owning input command. Date operation is ready to execute after dependencies satisfied. Date operation was started running (executing). Number of attempts to start operation running Maximum number of retries allowed before failure. Number of seconds delay between attempts at executing. Date when operation will fail if execution remains stalled. Date operation stalled during execution. Date execution completed. Text info set on completion. True if operation succeeded, false if failed. Code for post operation creation function to be run. If none then zero. Date all processing of operation finished, all post operations generated, or command cancelled, or command timed out. User cancelling implemented. Visible or not. User description. the TROUCO may not be
DATECR DATERD DATERN NRETRY MAXTRY WAITIM ENDTIM DATESL DATECM MSTEXT TRPASS POPCOD DATEND
date date date int int int date date date text log int date
5:10
12.0
Values of OPSTAT state attribute and order of change WAIT READY STALLED The operation is waiting until it is independent of any other operation/command. DATECR is set. The operation is independent and ready to execute. DATERD is set. The operation could not be executed. State will later return to READY (ready for retry), or to TIMEDOUT. DATESL is set. The command has started running. DATERN is set, NRETRY is incremented. A reply acknowledgement has been returned to the executing location. DATECM, TRPASS, MSTEXT are set. Post operations could not be created. State will later return to COMPLETE ready for retry, or to TIMEDOUT. Any required post operations have been generated using the result of this command. DATEND is set. The command will not be executed now due to dependency rules. DATEND is set. The command has been cancelled by owning TRINCO by a user. DATEND is set. The command has had the number of sends exhausted, or maximum time exceeded. DATEND is set.
5.8
Failures and Successes are propagated back to the originating location as messages as soon as they are generated and before the full result is handed back. These are finally stored under TRMLST as TRSUCC and TRFAIL elements. All the list elements have no user attributes.
5.9
5:11
12.0
generate messages relating to transaction events (sends, acknowledgements etc.) receive messages from the execution of commands at other site receive transaction event messages forwarded through other site remote operations.
Operations and output commands have a TRSUCC attribute stating a success or (relative) failure. Each point of failure will generate a single TRFAIL element (e.g. failure to claim an element). Each point of success will generate a single TRSUCC element (E.g. an element claimed). The attributes of TRSUCC and TRFAIL elements are equivalent. They include: A Reference to an element involved in the operation (e.g. the ref of a claimed element) A double integer code relating to a PDMS message or error (0,0 if not known or relevant) A text string which is a representation of the said message or error. An integer qualifier to be used for such things as session numbers etc.
The result of a command (TROUCO) is the sum of all TRSUCC and TRFAIL elements owned by its operations and output commands. All of these are communicated back to either the user (if it is a local command) or propagated to the originating site (if it is a foreign command). In the latter case the compounded errors will appear under the relevant originating TROUCO operation and hence onwards and upwards Whether a TROPER itself is classed as a success is determined by its execute method. Input Commands are successes if all its operations AND output commands are successes. An output Command is a success if the input command it spawned returns a success. Results are only passed on to the generating TROUCO when the input command is totally finished. Messages are sent immediately they are generated before waiting for operation or command conclusion. They go the same route as the result, being compounded by a TROUCO and transmitted to other site TROPER elements. They are only stored under the final TRINCO generated from a USER command.
5:12
12.0
Attributes for elements %TRSUCC and %TRFAIL DATEMS MESNUM[2] date int[2] Date success/failure raised. Message/error number relating to MSTEXT or 0,0 if none available. This can be used as an indication of the severity of a failure. Any result text (not passed on). Data type indicates significance of MESQUA, MSREF, MSDTXT. Data qualifier. Data refno corresponding to the error. Data text of the result/error. Name of location that generated the success/failure Source command type number (if generated by a TRINCO). Source operation type number (if generated by a TROPER). Pseudo-attribute, which combines the OPTYPE (Operation Number) and COMMTYPE (Command Number) attributes. Allows you to query the member operations of a command independently of whether the operations are TROUCO or TROPER. It combines the TRCNUM and TRONUM queries (these are attributes of TROUCO and TROPER respectively). Attributes for element %TRMESS DATEMS MESNUM[2] MSTEXT MSLOC MSSENT TRCNUM TRONUM TRTYPE Date int[2] Text text log int int text Date success/failure raised. Message/error number relating to MSTEXT or 0,0 if none available. Message text. Name of location that generated the success/failure. Unused. Source command type number (if generated by a TRINCO). Source operation type number (if generated by a TROPER). Pseudo-attribute, which combines the OPTYPE (Operation Number) and COMMTYPE (Command Number) attributes.
5:13
12.0
5:14
12.0
Command Summary
This chapter lists the ADMIN commands in functional groups. Details of the commands are given in Command Details in alphabetical order of command name.
6.1
Project Definition
ACCESS ACRADD ACRREM ADD AUTHENTICATION AUTHUSERREM/OVE CHANGE Changes the access rights of the specified user to PDMS modules. Adds a named ACR to the current ACR Group. Removes a named ACR from the current ACR Group. Places a named DB at a specified position in the current MDB list. Switches authentication user on/off. Removes authenticated user. Changes database access type, and the claim mode for multiwrite databases. (In a Global project, also changes primary location) Changes the description of the specified user, team, database or MDB. Changes the name of the specified user, team, DB or MDB. Copies a DB, MDB, Team, User, Module or Stamp. Creates a DB (including Extract DBs), MDB, Team, User, Windows NT Authenticated user or Module. Moves a DB to a specified position in the current MDB list. Adds a Database or DB Set to the current DB Set. Makes a DB non-current. Removes the specified element from the project. Removes a DB or DB Set from the current DB Set Replaces the current DB by a non-current DB.
CDESC CNAME COPY CREATE CURRENT DADD DEFER DELETE DREMOVE EXCHANGE
6:1
12.0
Removes a database which has been included from an external project. Includes databases from another project in the current MDB. Lists authenticated users. Creates a DB Set, Role, Scope, Access Control Right (ACR) or ACR group. Also used to create a new TrueType font element (TTFONT) Adds descriptive information to project definitions. Saves the structure or contents of a project in a named file. Removes a DB from an MDB. Sets the current MDB, Team or DB Set. Adds Users to the current Team. Removes Users from the current Team. Adds specified PDMS users to authenticated user. DEFAULT. Sets the specified PDMS user as the default PDMS username for the authenticated user. Removes the specified PDMS user from the authenticated user. Queries the authenticated user. Queries the authentication status.
6.2
Project Administration
BACKTRACK EXPUNGE EXTRACT LOCK MAXUSERS MERGE CHANGES MESSAGE MOVE NEW STAMP Backtrack a database to a previous session. Removes users from the Project and releases claimed elements in databases. Control of database extracts Locks the Project Database so that Users cannot enter. Maximum number of users for a project. Merges the changes made to a database over several sessions. Sends messages to other users. Moves a DB to a different area. Creates a new stamp.
6:2
12.0
Backtrack a database to a previous session. Backtrack a database to a previous session. Unlocks a locked database.
6.3
PING PREVOWNER PURGE RECOVER REMOTE REMOTEMESSAGE RENEW REORDER SET SORTALLOCATE SYNCHRONISE
6:3
12.0
Changes the Administering Location of a Satellite. Generates a directory containing copies of all database files, ready for transfer to a Location. Updates current Location and an immediate neighbour. Remote database query.
6.4
Module Definition
EDIT MODULE Enables project module entries to be edited. Creates an entry for a module in the System DB.
6.5
Font Definition
FONTDIRECTORY FONTFAMILY TTFONT Sets the font directory name. Defines a font family. Changes the deifnition of a TrueType font, that has previously been created with the NEW TTFONT command.
6.6
Querying
LIST QUERY STATUSSESSION SYSTAT Lists Project Information Queries information about ADMIN elements. Gives information about the current state of the Project. Gives information about users accessing the project.
6.7
6:4
12.0
Sends command input and output to a file. Updates the Project Database. Equivalent to ALPHA FILE END.
6.8
Stand-alone:
CHECK ERRORFILE Starts the integrity checking. Specifies the name of the file containing the error and warning messages when DICE is used in stand-alone mode. Checks that all external references point to DBs of appropriate types. Maximum number of errors found before data integrity checking is abandoned. Maximum number of warnings found before data integrity checking is abandoned Specifies what happens when DICE finds an error. Produces a summary of information about the database being checked. Exits from DICE in stand-alone mode. (Equivalent to FINISH)
6.9
Reconfiguration
BRIEF DUMP ERRORS FILE Brief output to pass 2 reconfiguration. Writes a reference number index to the given file. Sets an upper limit on the number of errors that are acceptable during Pass 2 of a reconfiguration. Sets the output destination for reconfiguration messages (see Chapter 3).
6:5
12.0
FROM FULL LOAD RCFCOPY RCFUPDATE RCFUPGRADE RECONFIGURE REINIT RESETXREFS TO UPGRADE VB XREF
Specifies the source database for reconfiguration. Gives full output from pass 2 reconfiguration. Loads the reference number index from the given file. Defines the part of the database to be copied from the source DB to the destination DB. Updates reference pointers into reconfigured database. Consult AVEVA Solutions Support. Starts reconfiguration. Re-initialises the reference number index. Consult AVEVA Solutions Support. Specifies the destination database for a reconfiguration. Produces macros to upgrade a project to a new version of PDMS. Gives very brief output for pass 2 reconfiguration. Consult AVEVA Solutions Support.
6:6
12.0
Command Details
The commands are described in this chapter in alphabetical order of command names. The descriptions are usually under subheadings of Function, Description, Examples, Command Syntax, and Related Commands. The syntax of commands is shown by syntax graphs. These are discussed in the first two sections. The third section contains the command descriptions.
7.1
CReate
can be input in any of the following forms:
FONTDirectory name
means that to set the name of the Font Directory to newfonts, you enter:
FONTD newfonts
Syntax graphs are read from top left to bottom right. The start point is shown by >, and you can follow any path through the graph until the exit point, shown by >, is reached.
7:1
12.0
Points marked with a plus sign (+) are option junctions which allow you to input any one of the commands to the right of the junction. For example: >----+--- ABC -----. | | |--- PQR ------| | | --------------+--->
means you can type in ABC or PQR or just press Enter to get the default option. Text in angle brackets <. . . > is the name of another syntax graph. This convention is used for syntax which occurs in many places. The graphs referred to are described at the end of this section. For example: >----+--- ABC -----. | | |--- PQR ------| | | |--- <dia> ----| | | --------------+--->
means you can type in ABC or PQR or any command allowed by the syntax given in diagram <dia> or just press Enter to get the default option. Points marked with an asterisk (*) are loop back junctions. Command options following these may be repeated as required. For example: .-----<-------. / | >---*--- option1 ---| | | |--- option2 ---| | | --- option3 ---+--->
means that you can enter any combination of option1 and/or option2 and/or option3, where the options can be commands, other syntax diagrams, or command arguments. The simplified format: .----<------. / | >---*--- name ----+--->
means that you may type in a list of PDMS names, separated by at least one space.
7.2
7:2
12.0
A text string of three alphanumeric characters, beginning with a letter. For example: 'CAM, A99' or abc, the LOCID of a LOC element. A PDMS general identifier <gid> which points to a LOC element. For example: / LOCATION_AAA
<when> >--+-- BEFORE --. | | -- AFTER ---+------ <date> --------. | | |------ SESS n --------| | | -- STAMP stampname ---+---> <date>
7.3
7:3
12.0
7.3.1
CREATE
7.3.2
7:4
12.0
7.3.3
7.3.4
ADD STEELN/STEELN 1
Place DB STEELN STEELN at the head of the current MDB list Command Syntax: .-------------<--------------. / | >-- ADD ---*--- dbname ---+--- integer ---| | | ---------------+---> Related Commands: REMOVE, DEFER, CURRENT, EXCHANGEREMOVE, DEFER, CURRENT, EXCHANGE
7:5
12.0
7.3.5
7:6
12.0
The administered location will still be able to lock or isolate the project locally. It will also be able to administer its primary constructor databases by using the REMOTE <loc> command, where <loc> is its own location identifier, followed by one of the normal commands:
7:7
12.0
Querying:
Returns the true current location Returns the currently administered location
7.3.6
7:8
12.0
the DBALL element at both the Hub and the Satellite lists all the allocated databases before continuing. Note: If the transaction database for a location is being allocated, this command is not recorded in the transaction database. It is not normally necessary to allocate it or change its primary location explicitly. Note: The OVERRIDE PROPG option cannot be used with a deferred time. Examples:
7:9
12.0
Querying: --- Q DBALL ---> >--- Q DBLC ---> At a location, shows the list of allocated DBs At a DB, shows the list of locations that have the DBs allocated
7.3.7
7.3.8
AUTHENTICATION
Function: Switches Windows NT authentication ON or OFF.
7:10
12.0
Examples:
7.3.9
AUTHUSERREM/OVE
Function: Removes Window NT authenticated user. Examples
AUTHUSERREM/OVE fred.bloggs1
Command Syntax: >- AUTHUSERREMOVE --- authuser ---> Related Commands: LIST AUTHUSER, USERADD TO, USERREM/OVE FROM, CREATE AUTHUSER, AUTHENTICATION
7.3.10
7:11
12.0
If you try to backtrack over any stamped sessions to a previous session, you will receive an error message. Backtracking over stamped sessions is not allowed. You must remove the stamp from the intervening sessions before you backtrack. BACKTRACK removes the sessions permanently. The related command REVERT adds a session containing the data for the specified old session. The backtracked database is written to a new file. This is done to avoid the situation where secondary database files in a Global project could still contain removed sessions. This situation would cause propagation failures if further sessions were added to the backtracked file. Note: For extracts, the REVERT command is used instead of BACKTRACK. Examples:
7:12
12.0
7.3.11
BRIEF (Reconfiguration)
Function: Gives brief output from pass 2 reconfiguration. This is the default. Examples: A short example of brief output is shown below. Compare with very brief output from the VB command.
*** Pass one initiated *** *** Pass one completed *** *** Pass two initiated *** EC LIBY #92/842 =16/2404
(24,90) Warning! library number 242 already exists in the project. Duplicate libraries should not be used in the same MDB EC DEPT #16/805 =16/2408 Phase one complete - starting phase two #EAE SHEE #88/842 =16/2417 /DR1/S5 IDLN: The head of the current element does not contain the attribute given #EAE SHEE #69/808 =18/2408 /DR1/S4 IDLN: The head of the current element does not contain the attribute given #EAE SHEE #53/819 =22/2402 /DR1/S3 IDLN: The head of the current element does not contain the attribute given ***Reconfiguration Completed 0 Elements were not defined in DDL 0 Elements have been lost 0 Elements are no longer named 3 Attributes were incorrectly defined 0 Elements were not inserted.
Command Syntax:
7.3.12
7:13
12.0
Description: The command to be cancelled must be in the ACKNOWLEDGED, READY, RECEIVED or STALLED state. See TRINCO element (Input Command) for information about the different states. A READY command cannot be cancelled if it has running operations. Examples:
7.3.13
USER TEST/TEST This is a test user TEAM TEST This is the test team DB TEST/DESI The test design database MDB TEST This is the test MDB
Command Syntax: >--- CDesc ---+--| |--| |--| --Related Commands: USer username/password text ---. | TEam name text ----------------| | MDB name text -----------------| | DB dbname text ----------------+-->
7:14
12.0
CNAME, CHANGE
7.3.14
Description: By default, databases are created with UPDATE access type, which means that they can be opened with one writer and n readers. DESIGN, DRAFT (PADD), CATALOGUE and ISODRAFT databases can be multiwrite databases, which allows more than one user to write to the same database. Multiwrite databases can have their claim mode set to IMPLICIT, in which case any element which is modified will be claimed automatically. Alternatively, the claim mode can be set to EXPLICIT, in which case users must claim elements before they can modify them, using the CLAIM command in the constructor modules. For more information, see the Reference Manual for the module. The CHANGE command can be used to change the access mode from UPDATE to MULTIWRITE, and from MULTIWRITE, to UPDATE. It can also be used to change the claim mode of Multiwrite databases from IMPLICIT to EXPLICIT, and from EXPLICIT to IMPLICIT. Note: You cannot set the controlled attribute, which means that access is controlled by an external system, using this command. If the database has an extract database created from it, the access mode must stay as Multiwrite. If the access mode of a database used as a foreign database is changed, you should use the CHANGE FOREIGN command in the project which has included the foreign database to update the project. Both UPDATE and MULTIWRITE databases can also have their CONTROLLED attribute set. Setting the PROTECTION parameter will disallow copying extraction of data between projects or users which are not members of the protected database. An optional expiry date may be specified. CHANGE dbname PROTection [ ON | OFF ] [EXPires future-date ] In a Global Project, the CHANGE command can be used at the Hub to change the primary location of a database. The CHANGE PRIMARY command cannot complete while there are users in PDMS with write access to the database. The command will eventually complete once all such users have left PDMS. You may need to use EXPUNGE to remove phantom users. After the CHANGE PRIMARY command has been issued, users in PDMS with write access to the database can continue to modify the database, even if GETWORK is used. Once they have made a module switch, the database will become read-only.
7:15
12.0
If a CHANGE PRIMARY command fails, the previous primary location will normally be recovered automatically. If the recovery fails (for example, the daemon is not running), you can recover the previous Primary location using the command: PREVOWN dbname Use of the PREVOWN command should be avoided if possible. Offline locations Before issuing a CHANGE PRIMARY command to or from an offline location, all users should have left PDMS at the old primary location. The TRANSFER command should first be used to bring the database at the new primary location up-to-date. Any modifications to the database at the old primary location subsequent to this TRANSFER will be lost. Only after this TRANSFER is it safe to issue the CHANGE PRIMARY command. Examples:
7:16
12.0
Note: On the following Change...Primary Commands The new Primary Location will receive all outstanding updates of the database from the current Primary Location. Note: Offline Locations: The Primary Location of a Database cannot be changed directly between an off-line satellite and an on-line satellite. The Primary Location of the database must first be changed to the Hub. The <date> option is not allowed for off-line Locations.
The following command can only be used at the Hub of a Global project:
Note: The CLAIM OFF option is only applicable to Controlled databases. The CLAIM IMPLICIT and CLAIM EXPLICIT options are only applicable to Multiwrite and Controlled databases.
7:17
12.0
Querying: >--- Query DB dbname ---> >--- Q PRMLOC ---> Related Commands: PREVOWNER, TRANSFER (Global only) At a DB, shows the primary location.
7.3.15
For information about using DICE (the PDMS Data Integrity Checker) as a stand-alone program, see Stand-Alone DICE. Stand Alone DICE. In a Global Project, both Primary and Secondary databases can be DICE checked. This enables you to check a number of locations to find, for example, a valid version of a database which has been corrupted at its primary location. To check a database at a remote location, prefix the CHECK command with REMOTE <loc> command, where <loc> is the Location identifier. See the REMOTE command for examples. Note: Remote checking uses stand-alone DICE. When a DICE report indicates that buckets have been lost, normally this would require the master database to be patched. However in a global project, this error is non-fatal if there are working extracts. These databases are non-propagating and only exist at the primary location of their extract owner. This results in the error report, since the buckets for working extracts are not accessible at the primary location of the master db.
7:18
12.0
Examples:
CHECK SYSTEMDB
Checks the integrity of the projects System DB. In a Global Project, the current administered System DB is checked.
CHECK COMMDB
Checks the integrity of the projects Comms DB.
CHECK MISCDB
Checks the integrity of the projects Misc DB.
CHECK GLOBALDB
Checks the integrity of the projects Global DB.
CHECK PROJECT
Checks the integrity of all DBs in a project, including the System DB, Comms DB and Misc DB (but not the virgin DBs). The DBs are checked automatically by DICE in the following order: The System DB The Comms DB The Misc DB The user-accessible DBs, which are checked team by team
7:19
12.0
Note: All the CHECK syntax except CHECK GLOBALDB can be applied to a remote Location in a Global Project by prefixing the command by REMOTE <loc>, where <loc> is the Location identifier. See the REMOTE command for examples. In stand-alone mode: .-------<------. / | >--- CHEck --- FIles --*--- filename ---+---> Related Commands: CHECKOPTION
7.3.16
7:20
12.0
A warning is identified if DICE encounters, for example, a fault with a reference to an external DB.
In BRIEF mode, checking is stopped when the first error is encountered; that is, DICE simply determines whether or not the DB is corrupt. This is the default mode. In FULL mode, DICE continues checking the whole DB or file, listing all errors and warnings, until a prescribed maximum error or warning count is exceeded, when checking of that DB is abandoned. Occasionally DICE will stop before processing the whole DB. This will happen when the error is so severe that it is not worth continuing; for example, if a database has been truncated. The default setting for the maximum error count and maximum warning count is 50, but you can specify different numbers by using the MAXERRORS and MAXWARNINGS options. STATISTICS ON causes DICE to produce a statistical summary of the DB, including its size, the number of elements contained within it, etc. STATISTICS OFF specifies that no statistics are to be gathered during the checking. This is the default setting. An example of the output from DICE when statistics are requested is as follows:
OVERALL STATISTICS ================== Total no. of entries in Name Table = 111 Total no. of elements checked = 782 Total no. of ref attributes found = 726 Total no. of external references = 0 Checking External References
The elements in some types of DB have reference or reference array attributes which can point to elements in other DBs. If you use the EXTERNAL option, DICE will check that all external references point to DBs of appropriate types. For example, a reference attribute in a Design DB which points to a Draft (PADD) DB must be illegal, but a reference attribute pointing to a Catalogue DB will be accepted. This command cannot be used in stand-alone mode because only one DB file can be accessed at a time. EXTERNAL NOCHECK is the default. In this mode DICE does not cross-check any references to other DBs. If EXTERNAL CHECK is specified, the following tests are applied to each external DB to which reference is made: Does the referenced DB exist? Is the referenced DB of a valid type? Is the position pointed to within the limits of the referenced DB? Note that in the case of a DB which has copies, DICE only checks that the position pointed to is within the limits of the largest copy.
A non-fatal error message is produced for each invalid external reference found. If you specify the EXTERNAL CHECK option, you can specify a preference MDB. In this case, DICE will check external references to databases which are current within the given MDB, before checking other databases in the project. This option is mainly relevant when extracts are used, which means that there may be many databases with the same database number in the project, and so it is less relevant to Global projects.
7:21
12.0
Once set, the preference MDB remains current until another EXTERNAL CHECK PREFERENCE command is entered to set a new MDB, or to specify that none is to be used, (though the setting will become irrelevant if EXTERNAL NOCHECK or EXTERNAL REJECT is entered). Using just EXTERNAL CHECK to switch external setting back on will not affect the current preference MDB. The EXTERNAL REJECT option should normally be chosen only when you are certain that the DB which is being checked should not contain any external references. If this setting is used, any external reference found in the DB will be reported as a fatal error and further checking will be abandoned. Note that when the CHECK FILES option is used, no external reference checking can be done for that file and EXTERNAL NOCHECK will be assumed. The CLAIM options are only relevant to extracts.
Extract Claimlists
The CLAIM ON option (the default) will check that the claim list in an extract corresponds with the claim list in its master database. The following error messages may be produced: 700: 702: 703: 704: Element ref/ref is not in parent extract claim list Element ref/ref is claimed to another user/extract Element ref/ref needs claiming to child extract in parent extract Element ref/ref needs clearing in parent extract claim list
If PATCH ON has been selected, then an attempt is made to patch errors of type 701, 703 and 704, and these cases will be treated as warnings rather than errors (and will therefore not terminate the check even if MODE FULL has not been selected). For cases 701 and 703, the patch attempts to claim the element from the parent extract (and continues up the extract hierarchy if necessary). If successful, the following message will be written: 701: PATCH: Element ref/ref claimed in parent extract
For case 704, the patch attempts to release the element from the parent extract. If successful, the following message will be written: CHECKOPTION (continued) 704: PATCH: Element ref/ref cleared from parent extract claim list
If the attempted patch is unsuccessful, the following error will be raised: 537: Attempt to patch failed
There is no patch for errors of type 702. (Patches may also be attempted for some other extract problems.)
7:22
12.0
Command Syntax:
>--- CHECKOption ----+| | | | | | | | | || | | || | | | | || || || | | EXTernal --+- CHECK -+-----------------------. | | | | - PREFerence -+- NONE -| | | | | - mdb --| | | |-- NOCHeck ----------------------| | | -- REject -----------------------| | MOde -------+-- FUll ------------------------| | | -- BRief -----------------------| | STATistics -+-- FULL ------------------------| | | |-- ON --------------------------| | | -- OFF -------------------------| | MAXErrors n ---------------------------------| | MAXWarnings n -------------------------------| | CLAIM ------+-- ON --------------------------| | | -- OFF -------------------------| | PATCh ------+-- ON --------------------------| | | -- OFF -------------------------+->
7.3.17
7:23
12.0
Examples:
CN DB TEAMNAME/GBPADD TEAMNAME/GBDRAFT
Change DB GBPADD to GBDRAFT if GBDRAFT does not exist.
CN TE GEORGEB GEORGEC
Change team name GEORGEB to GEORGEC. Command Syntax: >-- CName --+-- USer --- username username ---+--- /password---.
| | | | ----------------| | | |--- DB --- dbname dbname ---+--- OVER ------------| | | | | ---------------------| | | |--- MDB --- mdbname mdbname ----------------------| | | --- TEam -- teamname teamname --------------------+->
7.3.18
7:24
12.0
If the PROTection parameter was set during the creation of a database then a copy command will not be permitted. Examples:
7:25
12.0
Command Syntax:
>- COpy -+- DB dbname -+- FROM PROject projid USer id pass -. | | ------------------------------------+-> continued continued --- TO dbname -+-- TO AREA n --. | | ---------------+-- TO FINO filenumber --. | | ------------------------+-> >- COpy -+| | | || || | | | | || TEam teamid TO teamid -+- EXCLuding USERs -------------------------. | | -------------------------------------------| | MDB mdbname TO mdbname --------------------------------------------| | USer word TO word name -+--- FRee ---------------------------------| | | |--- GEneral-------------------------------| | | ------------------------------------------| | STAMP stampname1 TO stampname2 ------------------------------------| | MODule -+- integer ---. | | | | - moduleid --+- TO integer moduleid ----------------------+->
7.3.19
7:26
12.0
Before a newly created extract can be used at a satellite, all its owning extracts must have been allocated there. If the immediate parent extract is secondary at the satellite and there are no scheduled updates, it should have been synchronised since the new extract was created. Note: When the daemon is used to create an extract in a Global project, the CREATE EXTRACT command includes a recovery operation to restore the primary location of the database in the event of failure of the command, prior to its Allocate operation. Therefore, the PREVOWNER command is not usually needed after a failure of CREATE EXTRACT. However, the CREATE Allocate operation does not have an automatic recovery operation and, in the unlikely event of this failing, PREVOWNER may be needed. In a Global Project, you can only create Teams and Master Databases at the Hub. Extracts can be created at any authorised location. Working Extracts can only be created at locations where the owning extract database is Primary. Offline Locations: Working extracts cannot be created at an offline location that is administered by the Hub. The offline location must be locally administered. Authorised locations: A location is authorised to create extracts (for itself or an administered location) if its NOEXTC attribute is false. The Project hub is always authorised to create extracts. Examples: Creating Teams, Users and MDBs
CR TEAM PIPING
Create Team PIPING
CR MDB /STEEL
Create MDB /STEEL
CR USER FRED.BLOGGS1/ABC
Creates user Fred.Bloggs1 (Non alphabetic user names are valid)
CR AUTHUSER NAME
Creates a NT authenticated user which should be the name of a valid windows user.
7:27
12.0
Creating Master Databases Note: If the SET TEAM command has not been used to set the current teamid, then the dbname must be prefixed by the name of the team which owns it
7:28
12.0
CREATE DB TRANSACTION/LON
Create transaction db for location with LOCID LON. Note the omission of the database type. Transaction databases have a special naming convention which associates them automatically with the location. This database is automatically created with the correct primary location. These arecreated as OVERWRITE databases.
7:29
12.0
cont
cont >-- ACCess -+- UPDATE -----. | | +- CONTRolled -. | | - MULTIWrite -+- CLAIM -+- EXPLicit -| | | - IMPLicit -+--------+-> cont
cont >
cont >---+-- EXTNO n -. | | ------------+- DBNO n -. | | ----------+-- FINO n --. | | ------------+-- DESC text --. | | ---------------+--->
are alpha numeric character strings up to 50 characters long. The following characters should be avoided:-|@$/*. passwd is an alphabetic character string up to six characters long. is a normal PDMS name consisting of a slash (/) followed by up to 31 alphanumeric characters. is a 32-character name
name dbname
7:30
12.0
Extracts
>- CReate MASTER team/db ABOVE team/db ----> cont
>- CReate ---+--- EXTRact ---. | | --- VARiant ---+--- team/db FROM team/db ---->
cont
>- CReate EXTRact team/db FROM team/db -+-------------------. | | - AS AT SESSION n -+--> cont >- CReate VARiant team/db FROM team/db --------------------> >- CReate WORKing EXTRact FROM team/db FOR user ----------> cont cont
cont >---+- IN AREA n -. | | -------------+- CONTROL -. | | -----------+- CLAIM -+- IMPLicit -. | | | | - EXPLicit -| | | ----------------------+--> cont Standard projects: cont >--------+- EXTNO n -. | | -----------+- DESC text -. | | -------------+-->
Global projects: cont >-+- EXTNO n -. | | -----------+- REFBLOCKS n -. | | ---------------+- AT <loc> -. | | ------------+- DESC text -. | | -------------+->
The REFBLOCKS option is used to allocate a block of reference numbers. See Running Global Projects for more details. The AT <loc> option allows the Hub or an administering location to create an extract database whose primary location is at the specified satellite.
7:31
12.0
The name must be the LOCID of a valid Location. Users, Teams and MDBs
>- CReate -+- USer userid passwd -+--- FRee ------. | | | | --- GEneral ---| | | |- TEam teamid ------------------------+-- DESC text ---. | | | | ----------------| | | - MDB name --------------------------------------------+->
Authenticated User
>- CR/EATE --- AUTHUSER --- authuser --->
Querying:
>--- Query --+-| |-| |-| |-| -USer userid ---. | DB dbname -----| | MDB name ------| | Authuser ------| | TEam teamid ---+-->
Related Commands: SET, MODULE, CHANGE, NEW, LIST AUTHUSER, USERADD TO, USERREM/OVE FROM, AUTHUSERREMOVE, AUTHENTICATION
7.3.20
7:32
12.0
Examples:
CURRENT MASTER/AREA-D 2
Move DB MASTER/AREA-D to be at position 2 in the current MDB list Command Syntax:
.------------<----------. / | >-- CUrrent ---+--- dbname ---*--- integer -- dbname --- | | --- integer --+-- integer -------------------->
7.3.21
.----------------<------------.--<---. | | / .----<-------. | | / / | | | >-- DADD --*--- DB -------*--- dbname ---+---' | | | | .-------------------<------------. | | / | | | / .-------<-------. | | |/ / | | | *--- DBSET ----*--- dbsetname ---+---+---+---> /
7:33
12.0
7.3.22
7:34
12.0
Examples:
The KEEPMDBS option means that the database will not be removed from MDBs at the satellite although its database file will be deleted and the database removed from the location's allocation list. This option is useful when a database is being de-allocated temporarily for housekeeping procedures. A replacement database with the same details will be available for use immediately it is re-allocated without any need to modify MDBs.
7.3.23
7:35
12.0
Description: Moves a DB from the current list of an MDB into the deferred list of an MDB. You can specify the position in the list by giving an integer. Examples:
DEFER MASTER/AREA-D
Make DB MASTER/AREA-D non-current. Command Syntax: .------<------. / | >-- DEfer ---+--- dbname ---*--- dbname --- | | --- integer --+-----------------> Related Commands: ADD, REMOVE, CURRENT, EXCHANGE
7.3.24
7:36
12.0
Offline locations: When a location is deleted, the system administrator must ensure that the system database for that location is deleted from all other locations. See Running Global Projects with PDMS for further information about deleting databases and extracts from a Global project. Examples:
DELETE DB PIPEN/DESI
Deletes Database PIPEN/DESI
DELETE MACRO 7
Deletes inter-db connection macro 7 in current project
DELETE MESSAGE 3
Deletes message 3 in current project
DELETE RUNFILE
Deletes runfile entry for current module.
DELETE STAMP
Deletes the stamp that is the current element. Global Projects only:
DELETE LOCATION
Deletes the current Location. This will remove the system database file for that location from all other locations. The location may be deleted provided all databases (other than its transaction database) have been deleted.
DELETE GRP
Deletes the current Location Group.
DELETE LCOMD
Deletes the current communication event.
7:37
12.0
Command Syntax:
>--- DELETE ---+--- USer ------+--- user--------------------------. | | | | ----------------------------------| | | |--- TEam ------+--- team_name --------------------| | | | | ----------------------------------| | | |--- DB --------+--- db_name ----------------------| | | | | ----------------------------------| | | |-- WORKing -+- EXTract --. | | | | | | - VARiant --+- FROM dbname FOR user -| | | |--- MDB -------+--- mdb_name ---------------------| | | | | ----------------------------------| | | |--- LOCation --+--- code -------------------------| | | | | |--- location_name ----------------| | | | | ----------------------------------| | | |--- GRP ------------------------------------------| | | |--- LCOMD ----------------------------------------| | | |--- MESSage n ------------------------------------| | | |--- MACro n --------------------------------------| | | |--- RUNFile --------------------------------------| | | |--- STAMP ----------------------------------------| | | | .--------<-------. | | / | | --- MOdule ----*--- integer ------| | | | | --- module_name --+---------------+-->
7.3.25
7:38
12.0
Examples: The following example assumes that both the Team and the DB Set have been set using the SET command.
7.3.26
DUMP (Reconfiguration)
Function: Writes a reference number index to the given file. Description: If required, the reference index should be written for each database. Examples:
DUMP /DUMP1
Write reference number index to named file. Command Syntax:
7:39
12.0
7.3.27
DUPLIC START
Initialise memory allocation etc.
DUPLIC CHECK
Perform duplicate name check on the Databases specified in the INCLUDE and EXCLUDE options, and exit. The list of Databases to be checked will be emptied. If you want to do another check, you must give the DUPLIC START command again, redefine the list of Databases you wish to check, and give the DUPLIC CHECK command again.
7:40
12.0
Other Examples: Other options which you can use to set up the list of Databases are as follows:
/00NEB0SED =15196/3964, 7004, =15192/24230, 7000 /00NEB0SFD =15196/3965, 7004, =15192/24231, 7000 /00NEB0SFE =15196/3966, 7004, =15192/24232, 7000
If both MASTER and COPY DBs occur in the list then the DB refs and nos will be identical. If necessary, use the LIST DBS command to associate a DB name with a DB number. Command Syntax:
>--- DUPLICatenames START ---> >--- DUPLICatenames FIle filename ---> >--- DUPLICatenames INclude ---+--- ALL ---------------------. | | | .----<-------. | | / | | |--- DB ---*--- dbname ---+---| | | |--- LIST --------------------| | | --- CLEAR -------------------+---> .----<-----------. / | >--- DUPLICatenames EXclude ---+--- DB ---*--- dbname -------+ | | |--- LIST --------------------| | | --- CLEAR -------------------+---> >--- DUPLICatenames CHECK --->
7.3.28
7:41
12.0
Description: Enters edit mode (which continues as long as only command lines beginning with EDIT or MODULE are used) within which a project module entrys NAME, NUMBER, SECURITY, MODE, data file, RESUME file and IMACRO and BUFFER options can be edited. Examples:
7:42
12.0
7.3.29
ERRORFILE /%PDMSEXE%/MESSAGE.DAT
Command Syntax:
7.3.30
ERRORS (Reconfiguration)
Function: Sets an upper limit on the number of errors that are acceptable during Pass 2 of a reconfiguration. Description: If the specified limit is reached, reconfiguration is abandoned and the DB is left unaltered. By default, an unlimited number of errors can occur. Command Syntax:
7:43
12.0
7.3.31
.--------<----------. / | >-- EXchange ---*--- dbname dbname --- | |-----------------------. | | --- integer integer ---+---> Related Commands:
ADD, REMOVE, CURRENT, DEFER
7.3.32
EXCLUDE DB MASTER/STEELCATA
Remove named DB from current project. Command Syntax:
7:44
12.0
7.3.33
7:45
12.0
Examples:
EXPUNGE
Expunge all users. (This should be used with care.)
EXPUNGE 29f
Expunge user identified by given process number.
EXPUNGE DB dbname
Releases elements which have been claimed in a multiwritedatabase. These elements may be inaccessible after a user has exited abnormally. This is not allowed if there are current users accessing the DB.
EXPUNGE DB SYSTEM
Releases elements which have been claimed in a SYSTEM database.. These elements may be inaccessible after a user has exited abnormally. Command Syntax:
.-----<--------------------------------. / | >-- EXPUNGE --*-- process_id --------------------------| | | |-- user ---------+-- username ----------| | | | | -- slot nnnn ---------| | | |-- DB dbname ----+-- USER usernumber ---| | | | | ----------------------' | |--- DB SYSTEM ---. | | -----------------+------------------>
Note: All the EXPUNGE syntax can be applied to a remote Location in a Global Project by prefixing the command by REMOTE <loc>, where <loc> is the Location identifier. See the REMOTE command for examples. Querying: Q ACTIVE Related Commands: SYSTAT,
7:46
12.0
7.3.34
A non-fatal error message is produced for each invalid external reference found. The EXTERNAL REJECT option should normally be chosen only when you are certain that the DB which is being checked should not contain any external references. If this setting is used, any external reference found in the DB will be reported as a fatal error and further checking will be abandoned. If the DICE option CHECK FILES is used, no external reference checking can be done for that file and EXTERNAL NOCHECK will be assumed.
7:47
12.0
Examples:
No of references ________________ 41 4
>--- EXTernal ---+--- NOCHeck* ---. | | |--- CHECK ------+-- PREFERENCE | | --- REject -----+--->
The default is NOCHECK.
7.3.35
FLUSH RESET
FLUSHW
REFRESH
7:48
12.0
FULLREFRESH
Refreshes an extract and all its parent extracts - its ancestors. A full refresh takes place from the top of the database hierarchy downwards, ending with a refresh of the extract itself. Each extract is refreshed with changes that have been made to its parent extract. Writes the changes back to the parent extract, and releases the extract claim. Releases the extract claim: this command can only be used to release changes that have already been flushed. Drops changes that have not been flushed or issued. The user claim must have been unclaimed before this command can be given.
Note: That unlike the constructor modules, you can only perform these operations on a complete database in ADMIN, and so extract claiming has no meaning in ADMIN. For general information about using extracts in projects, see the AVEVA PDMS ADMIN User Guide. For information about using extracts in Global projects, see Running Global Projects with PDMS. In a Global project, Flush, release and issue may be executed remotely if the parent extract is not primary at the current location. In this case, FlushW is used and the database must be explicitly refreshed after completion of the flush. Offline locations: Extracts cannot be used which are primary at an offline location unless the entire extract hierarchy is primary at the offline location. This is because claim, flush and release commands can only be issued locally. There is no mechanism at an offline location to claim (etc.) from an online location.
7:49
12.0
Examples:
FLUSH --+------------. | | --- RESET --| FLUSHWithoutrefresh -| | RELEASE -------------| | ISSUE ---------------| | DROP ----------------| | FULLREFRESH ---------| | REFRESH -------------+- DB - dbname -->
Note: In ADMIN, you cannot carry out partial operations as you can in the constructor modules. The commands can only be applied to entire DBs.
7.3.36
7:50
12.0
Examples:
FINISH
Command Syntax:
7.3.37
FONTD /%PDMSEXE%
Command Syntax:
7.3.38
7:51
12.0
The directory where the font files are to be found must be specified using the FONTDIRECTORY command. The macro makemac.mac supplied with PDMS includes the following commands:
FONTF 1 UK STYLE 1 FONTF 2 UK STYLE 2 FONTF 3 UK STYLE 3 FONTF 4 UK STYLE 4 FONTD /%PDMSEXE%
For each font family, you can define an angle of slope between -85 and +85 degrees inclusive. The text can be sloped forwards (positive angles) and backwards (negative angles). Note: True-Type fonts are not defined in this way, these use the TTFONT element.
7:52
12.0
Examples:
FONTFAMILY font_no IR ir_no STYLE style_no ANGLE angle FONTFAMILY font_no FILE /abc BOLD /def ANGLE angle PROJECT MBCHARSET JAPAN ANGLE angle FONTFAMILY 1 IR 4 STYLE 1 FONTF 2 UK ITALIC FONTF 3 UK BLOCK FONTF 4 GREEK STYLE 1
Command Syntax:
.-------------------------<------------------------------. / | >-- FONTFamily ---*--- n ---*- IR number --. | | | | |- UK ---------| | | | | |- US ---------| | | | | |- GREEk ------| | | | | |- CYRIllic ---| | | | | |- LATIn 1 ----| | | | | |- LATIn 2 ----+-- STYle n ---------. | | | | | | |-- LIne ------------| | | | | | | |-- BLock -----------| | | | | | | |-- SErif -----------| | | | | | | |-- ITalic ----------| | | | | | | |-- SCript ----------| | | | | | | |-- TYpewriter ------| | | | | | | -- UWLIne ----------| | | | | - FILE filename -- BOLD filename --+- ANGLE n --| | | ------------+-->
Note: The IR number is the International Registration Number of the font. See ISO 8859. The font family number must be in the range 1-4 The style n must be in the range 1-7. The angle n must be in the range -85 to + 85 degrees. Negative angles slope the text backwards. Related Commands: FONTDIRECTORY, Q FONTS, NEW TTFONT, TTFONT Querying:
7:53
12.0
7.3.39
FROM (Reconfiguration)
Function: Specifies the source database for reconfiguration. Examples:
FROM DB MASTER/DESIGN
Source data is in database MASTER/DESIGN in current project
FROM SYSTEM
This command is used to reconfigure the System database. It is followed by the command RECONFIGURE. For more information, see Section 3. In a Global Project, this command is only available at the primary location of the System DB (the administering location).
FROM GLOBAL
This command is only available in a Global Project, at the Hub. The command is used to reconfigure the Global database. It is followed by the command RECONFIGURE. For more information, see Section 3. Command Syntax:
>--- From ---+--| |--| |--| |--| |--| |--| |--| --DBFile filename ----------------------------. | DB dbname ----------------------------------| | PROJect code dbname ------------------------| | SYSTEM -------------------------------------| | GLOBAL -------------------------------------| | FIles --------------------. | | | BINaryfiles --------------| | | | FORMattedfiles -----------+--- name name ---+-->
7:54
12.0
7.3.40
FULL (Reconfiguration)
Function: Gives full output from pass 2 reconfiguration. Description: All information output in BRIEF mode is given, plus a log of all elements successfully created and named. FULL mode is very verbose and its use is not generally recommended. Command Syntax:
7.3.41
7:55
12.0
Examples:
>-- GENerate LOCation <loc> --+--- ALLOCate -----. | | --- NOALLOCate ---+-->
Related Commands: INITIALISE For Offline locations: TRANSFER Querying:
7.3.42
7:56
12.0
7.3.43
HUBLOCATION LON
Relocates the Hub to location with identifier LON.
7:57
12.0
7.3.44
Examples:
7.3.45
7:58
12.0
When you first use a Global project, it is necessary to initialise the Hub. The Hub transaction database must be created before initialising. Examples:
INITIALISE
Command Syntax:
7.3.46
ISOLATION TRUE
Isolates the current Location.
ISOLATION FALSE
Connects the current Location.
7:59
12.0
Command Syntax:
>--- ISOLATion ---+--- TRUE ----. | | --- FALSE ---+--- AT <loc> ---. | | ----------------+--->
Querying:
7.3.47
LIST (Querying)
Function: Lists Project Information Examples:
LIST
Outputs date and time.
LIST USERS
Lists the Users in a project.
LIST MDBS
Lists the Multiple Databases in a project.
LIST DBS
Lists the Databases in a project.
LIST TEAMS
Lists the Teams in a project.
LIST COPIES
Lists the DBs in a project which have been copied and the filenames of the copies.
LIST ALL
Lists the Users, Teams, Databases and MDBs in a project.
LIST FILES
Lists the DBs in a project and their corresponding filena mes in the Project directory.
7:60
12.0
LIST MESSAGES
Lists inter-user messages.
LIST MODULES
Produces information on all the PDMS modules used by the project.
LIST MODULES 5
Produces information on module 5.
LIST MESSAGES
Lists inter-user messages.
LIST PASSWORDS
Lists users ids and passwords.
LIST TYPES
Lists the types of DB currently permissible.
LIST SIZES
Gives the sizes of all the DBs in a project.
LIST EXTERNAL
Lists DBs which are being shared from another project.
LIST MACROS
Lists inter-db connection macros.
LIST AREA 51
Lists DBs in Project Area 51.
LIST AUTHUSER
Lists Windows NT authenticated users.
7:61
12.0
Command Syntax:
.----------------------<----------------------. / | >--- LIst ---*-----------------------------------------------| | | |--- USers -------------------------------------| | | |--- MDBs --------------------------------------| | | |--- DBs ---+--- OF TYPE type ------------------| | | | | -----------------------------------| | | |--- TEams -------------------------------------| | | |--- FIles -------------------------------------| | | |--- COpies ------------------------------------| | | | .-------<---------. | | / | | |--- MOdules ---*--- integer -------| | | | | | | |--- module_name --- | | | | | -------------------------------| | | |--- MESSages ----------------------------------| | | |--- ALL ---------------------------------------| | | |--- PASSwords ---------------------------------| | | |--- TYpes -------------------------------------| | | |--- SIZes -------------------------------------| | | |--- MACRos ------------------------------------| | | |--- AREA --- integer --------------------------| | | |--- EXTernal ----------------------------------| | | |--- AUTHUSERS ---------------------------------| | | --- WORKing EXTracts --+----------.- FOR user -+---> | | - dbname -
7.3.48
LOAD (Reconfiguration)
Function: Loads the reference number index from the given file.
7:62
12.0
Examples:
LOAD /DUMP1
Read reference number index from named file and replace current index.
7.3.49
LOCK
Locks the Project database.
LOCK AT LON
ocks the Project database at the remote Location LON. Only available at the Hub of a Global Project or at the administering location for the location (in this example, the administering location for LON). Command Syntax:
7:63
12.0
7.3.50
MAKE GLOBAL
Command Syntax:
7.3.51
7:64
12.0
Description: In FULL mode, DICE checks the DB or files specified, listing all errors and warnings, until a prescribed maximum number of errors or warnings is exceeded. Checking of that DB is then abandoned. The default setting for the maximum error count is 50, but you can specify a different number by using the MAXERRORS command. Examples:
MAXERRORS 100
Related Commands: MODE, MAXWARNINGS Command Syntax:
>--- MAXErrors
integer --->
7.3.52
MAXUSERS 10
Command Syntax:
7.3.53
7:65
12.0
MAXWARNINGS 100
Related Commands: MODE, MAXERRORS Command Syntax:
>--- MAXWarnings
integer --->
7.3.54
7:66
12.0
Examples:
MERGE CHANGES /HVAC BEFORE 10:30 31 / 8 / 01 MERGE CHANGES /HVAC BEFORE 10:30 31 AUGUST 2001
Merges all the changes to the HVAC database before 10.30 am on the 31 August 2001. If the time is omitted, 11.59 is assumed. If the month is not given, the current month is assumed. If the year is not given, the current year is assumed. If there are any stamped sessions, they will be kept.
7:67
12.0
where when can be given in the form of a date or a session number, or, if the required sessions have been stamped, a stamp, as shown in the examples. See Notes on Syntax Graphs, for the full syntax of <when>. Note: All the MERGE CHANGES syntax except MERGE CHANGES GLOBAL can be applied to a remote Location in a Global Project by prefixing the command by REMOTE <loc>, where <loc> is the Location identifier. MERGE CHANGES SYSTEM applies to the currently administered system database. See the REMOTE command for examples. Related Commands: BACKTRACK, REVERT, REMOTE Querying: Q SESSION
7.3.55
The message will be displayed only to users already in PDMS when the command is given, and then only when they next change modules or leave PDMS. Examples:
mess team piping the latest pipe routing has been approved
7:68
12.0
Command Syntax:
>--- MEssage ----+--- ID text ------| |--- USer userid --| |--- TEam teamid --| |--- HOST ---------| |--- LOGIN --------| ------------------Querying: LIST MESSAGE Related Commands: DELETE MESSAGE, REMOTE MESSAGE (Global Projects only)
text ----------. | text ----------| | text ----------| | text ----------| | text ----------| | text ----------+-->
7.3.56
In BRIEF mode, checking is stopped when the first error is encountered; that is, DICE simply determines whether or not the DB is corrupt. This is the default mode. In FULL mode, DICE continues checking the whole DB or file, listing all errors and warnings, until a prescribed maximum error or warning count is exceeded, when checking of that DB is abandoned. Occasionally DICE will stop before processing the whole DB. This will happen when the error is so severe that it is not worth continuing; for example, if a database has been truncated. The default setting for the maximum error count and maximum warning count is 50, but you can specify different numbers by using the MAXERRORS and MAXWARNINGS commands, respectively.
7:69
12.0
Examples:
7.3.57
IMACRO Examples:
Module 78
DESIGN Security Free Mode DESI Default Mode PROP R Mode CATA R Mode DESI RW Resume /%PDMSEXE%/des
7:70
12.0
Command Syntax:
>- MODule -+--- integer module_name -. | | --- module_name integer -+- newline <runf> -->
where the <runf> keywords are defined as follows:
.--------------------------. / | >--- Open ---*--- ATTLIB filename --------| | | |--- SYMBOLFILE filename ----| | | --- MESSagefile filename ---+--> >--- Mode dbname ---+--| |--| |--| --RW --------. | Read ------| | None ------| | DEFault ---+--->
>--- Resume filename ---> >--- Security ---+--- FRee ---------. | | --- GEneral ------+---> >--- Buffer ---+--- integer -----. | | --- DEFault -----+---> >--- IMACRO name --->
Related Commands: LIST MODULES, DELETE MODULES, EDIT Querying:
.----------------. / | >--- Query MOdule ---*--- integer ------| | | --- module_name --+---
7.3.58
7:71
12.0
Description: This command may be needed if disk space is a problem. Databases can be stored in a different area, that is, a different directory from the Project directory. The directory must be created before the database is created, and an environment variable set to the pathname of the directory. For example: xxxnnn set to pathname
where xxx is the Project Code, for example, abc, and nnn is a number, for example, 001. When the database is created, the area number of the database must then be set to the corresponding value, in this example, 1. In a Global Project, this command can only be carried out at the Hub. The area directories must exist at all Locations to which the Database is allocated. Example:
7.3.59
7:72
12.0
7:73
12.0
LOC /name -----| | GRP /name -----| | LCOMD /name ---| | LCTIMD /name --+--->
7.3.60
7:74
12.0
Example:
7.3.61
PING LON
Checks that communications link to Location LON exists. Command Syntax:
7:75
12.0
7.3.62
Description: If a CHANGE PRIMARY command on a Database fails, the Database will be left with no Primary Location. However, the original Primary Location will be recorded, and this command is used to restore the original Primary Location. Similarly, if a HUBLOCATION command fails, and the Project is left with no Hub, this command will restore the previous Hub Location. If a SYSTEMLOCATION command fails, the PREVOWNER SYSTEM command will restore the previous System database Location. These three commands have built-in recovery operations to restore the previous primary location if they fail. The PREVOWNER command is provided to enable the previous location to be recovered in the following circumstances: If the daemon is down For offline locations To recover a failed change primary on the locations own transaction database If the CREATE EXTRACT command fails before it has reached its Allocate Primary command.
Note: PREVOWNER is not usually needed after a failure of this command since it contains an in-built recovery operation. However, the automatic recovery operation does not cover the CREATE command Allocate operation and PREVOWNER may be needed in the unlikely event of this failing. In all other circumstances it is better to await the completion of the in-built recovery operation, since this prevents incompatible changes being made by two competing users at different locations. Note: This command cannot be used to reverse a successful CHANGE PRIMARY, HUBLOCATION or SYSTEMLOCATION command.
7:76
12.0
Examples:
7.3.63
7:77
12.0
MESSAGE NUMBER
If you require information about multibyte character sets, please contact your local AVEVA Solutions Support Office, as listed on the copyright page of this manual. In Marine projects, the Project numbers should match the 8-character project identifier a defined by %ABC000ID%. Examples:
PROJ NAME STABILIZER PROJ DESCRIPTION CADC TRAINING PROJECT PROJ MBCHAR JAPANESE PROJ MBCHAR 87 (where 87 is the ISO Standard Font number).
PROJ MBCHAR LATIN FILE /lat_std BOLD /lat_bld PROJ CHARSET LATIN 2
The type parameter can be used to change the project sub type from between Pant and Marine. Since the transition is one-way, another command must be invoked first in order to activate the project type changing capability. An advisory message is displayed after the activation command.
TYPE ALLOWCHANGE It is now possible to convert the current project to Note: there is no way to reverse this action TYPE MARINE
The rationale for the distinction between Plant and Marine, as based on the constituent database sub types, is to restrict access to data from inappropriate modules. To enforce these restrictions checks are made at the database access layer to restrict access to data according to the subtype of the database and the family of the currently working modules. No indication is given that a read-only restiction applies when accessing a Plant database from a Marine module. Any attempt to modify data will return an appropriate read only error notification The following error text is displayed when an attempt is made to access a Plant database from a Marine module. This typically appears when loading an MDB that contains a Plant database; in this case the MDB open will also fail, returning the user to the Montor, or preventing the user from leaving MDB mode
7:78
12.0
Command Syntax:
>- PROJect -+-- NUMber text ------------------------------------------------. | | |-- NAMe text --------------------------------------------------| | | |-- DEScription text -------------------------------------------| | | |-- MESsage text -----------------------------------------------| | | |- MBCHARset -+- integer --. | | | | | | |- JAPanese -| | | | | | | |- CHInese --| | | | | | | |- LATIN ----+- FILE -+- name -+- BOLD name -. | | | | | | | | | | | | -------------| | | | | - DEFAULT ------------| | | | -------------------------------| | | | | | | | .-------<------' | | | | | | -+- KORean ---. | | | | | | | | - TCHINese -+--FILE name --+- ANGLE integer ---| | | | | -------------------+-> - CHARset -+- IR integer ---------. | | - LATIN -+- integer --| | | |- CYRIllic -| | | ------------+->
Querying:
>--- Q PROject --+-| |-| |-| |-| |-| |-| -NUMber -------. | NAMe ---------| | DEScription --| | MESsage ------| | CODe ---------| | MBCHARset ----| | CHARset ------+-->
Q PROJ ID returns the external project identifier 8 character alphanumeric ID defined by %ABC000ID%. An administrator can also query the project sub type (Plant/Marine) through the following syntax:
Q PROJ TYPE
7.3.64
7:79
12.0
Description: When updated database files and picture files are propagate or transferred, the existing versions will be retained if Users are accessing them. The files will have the suffix .admold. The main use of this command is to remove the old versions of these files. The PURGE DB option removes old versions of picture files from a given Database in any Project. Examples:
7.3.65
QUERY (Querying)
Function: Used to output a wide variety of information. In general, querying options are documented with the commands which they relate to. Some options which do not fit into this category are listed here. Note: That general PDMS commands for querying elements and attributes are also available.
7:80
12.0
Examples:
Q COPIES PIPING/AREA-A
List the copies of DB PIPING/AREA-A
Q DDL
Gives version number of System DDL (Design Data Language)
Q CLAIM SAMPLE/DESI
Outputs information about claimed databases
Q NEWREF old-ref
Gives the new reference corresponding to the given old reference
Q SESSION LAST
Outputs the date, user, and any comments saved with the given session
Q ACTIVE
Gives the active session number
Q NACCNT
At a DB element, gives the non-additive changes count. This value increases when a database is merged, backtracked or reconfigured. This attribute will return the value for the system database if used at STAT /*S, or in a Global project, for the global database if used at GSTAT /*GS.
7:81
12.0
Q HCCNT
At a DB element, gives the extract list changes count. This value increases when extracts are inserted or removed. Note: The superseded ELCCNT pseudo-attribute is retained as a synonym for HCCNT. HCCNT is available at /*S and /*GS elements as well as at DB elements.
Q CLCCNT
At a DB element, gives the claim list changes count. This value increases when elements are claimed or dropped without other changes to the database. Note: In a Global project, the above three attributes together with session information can be used to compare the state of the database at different locations. For information about this, see Running Global Projects with PDMS. Querying extracts
Q DBNAME
Gives the name of the database you are actually writing to.
Q CLAIMLIST
Gives a list of user claims in your current database.
Q CLAIMLIST EXTRACT
Tells you what you can flush.
Q CLAIMLIST OTHERS
Tells you what you can't claim, including user claims and extract claims. The following options are only available in a Global Project:
Q ADMLOC
Returns the currently administered location, which may be different from the true current location.
Q COMMS TO LON
Query state of comms link to location LON. (Equivalent to PING)
Q CURLOC
Returns the true current location. This command is useful when you are remotely administering another location: it returns the name of the actual location where you are working.
7:82
12.0
Q ISOLAT AT LON
Returns TRUE if the location LON is isolated.
Q LOCK AT LON
Returns the project lock at location LON.
7:83
12.0
Command Syntax:
>- Q --+- Authuser -------. | | |- Authentication -| | | |--- USer ---------| | | |--- TEam ---------+--- word ------------------. | | |--- DB -------. | | | | |--- COpies ---+--- dbname --------------------| | | |--- DBNO dbno --------------------------------| | | |--- MDB name ---------------------------------| | | | .-------<-----. | | / | | |--- MOdule ---*--- integer ---| | | | | | | --- word ------+---------------| | | |--- LOck -------------------------------------| | | |--- DDL --------------------------------------| | | |--- SET ---+--- TEam -------------------------| | | | | |--- DBSet ------------------------| | | | | --- MDB --------------------------| | | |--- PROject ----------------------------------| | | |--- SESSIONS --+-- SINCE --. | | | | | | |-- LAST ---+- n --+-----------| | | | | | - ON <date> -----+-dbname ---| | | |--- CLAIM dbname -----------------------------| | | |--- NEWREF oldref ----------------------------| | | |--- MAXUSers ---------------------------------| | | |--- ACTIVE -----------------------------------| | | |--- MACRO n ----------------------------------| | | --- INFOrmation --+--- dbname ----------------| | | --- SYSTEM ----------------+--->
7:84
12.0
For details of Q REMOTE, see under REMOTE Related Commands: LIST, Q REMOTE
7.3.66
RCFCOPY (Reconfiguration)
Function: Defines the part of the database to be copied from the source DB to the destination DB before reconfiguration.
7:85
12.0
Description: Must be given just before a RECONFIGURE command. Only elements that can exist at the level immediately below World can be specified. You must use RCFCOPY ALL if you intend to use the RECONFIGURE SESSIONS command afterwards, as the SESSIONS option is not valid if you carry out partial reconfiguration. Examples:
RCFCOPY ALL
Copies all of the elements in the list part of WORLD in the source DB into the list part of WORLD in the destination DB
RCFCOPY CATA
Copies the first root elements of type CATA to be copied from the list part of the WORLD in the source DB.
RCFCOPY SPEC
Copies the first root elements of type SPWL to be copied from the list part of the WORLD in the source DB.
7:86
12.0
7.3.67
RCFUPDATE (Reconfiguration)
Function: Updates reference pointers into reconfigured databases. In a Global Project, this command can only be given at the Hub. Description: Uses index of element reference numbers in source database against reference numbers in destination database. The RCFUPDATE command must be given immediately following a RECONFIGURE operation, or after a LOAD command. Examples:
RCFUPDATE DB MASTER/DESIGN
Updates references to the reconfigured DB from DB MASTER/DESIGN.
RCFUPDATE ALL
Updates references to the reconfigured DB from all databases in current project. Command Syntax:
>--- RCFUPdate ---+--- DB dbname -+--------------. | -- INTERNAL --| | | |--- MDB mdbname --------------| | ---------| |--- TEam teamname ------------| | | |--- ALL ----------------------| | | ------------------------------+-->
7.3.68
RCFUPGRADE (Reconfiguration)
Function: This command is used when an upgrade to a new version of PDMS is required.
7:87
12.0
Note: This command is normally handled automatically by the upgrade macros supplied with a new version of PDMS. You are advised to consult your AVEVA Solutions Support Office before using it. Command Syntax: >-- RCFUPGRADE --+-- ON ----. | | -- OFF ---+-->
7.3.69
RECONFIGURE (Reconfiguration)
Function: Starts a reconfiguration operation. You can specify that the reference numbers stay the same in the reconfigured database. You can specify that session information such as the original session comment, session number, username and original date stays the same in the reconfigured database. Description: You can specify that the reference numbers stay the same in the reconfigured database. The SAMEREF option will fail if: The database specified in the TO DB command has a different DB number from the database given in the FROM DB command. An element already exists with the same reference number. You can specify that session information stays the same in the reconfigured database by using the SESSIONS option: The option is not valid for SYSTEM, or GLOBAL DBs. The option is not available if you are doing a partial reconfiguration. You must use the RCFCOPY ALL command with RECONFIG SESSIONS. For extracts, RECONFIG SESSIONS will be assumed, even if the option is not given. For Draft DBs, the picture files will be ignored. The reconfigured data must go TO a file. After reconfiguration, data can be read back in from the file, replacing the original DB data. The SAMEREF option is assumed when reading the data. When reading in data created by RECONFIG SESSIONS, the DB number and extract number must be the same as the originating DB number and extract number. If errors occur when reading in data created by RECONFIG SESSIONS, the data is not saved unless you use the RECONFIG FORCE option.
The normal procedure for reconfiguring a database and maintaining the reference numbers is as follows: 1. Reconfigure from the target database to a file. 2. Delete the target database, and create a new one with the same DB number. 3. Reconfigure from the file to the new database. For Global projects, note the following: To reconfigure the Global Database in a Global Project, give the command FROM GLOBAL followed by RECONFIGURE. For more information, see Reconfiguration. In a Global Project, the TO NEW option is only valid at the Hub (see the TO command).
7:88
12.0
To reconfigure a satellite transaction database, reconfigure the DB to file, renew the file to empty it (see the RENEW command), stop the daemon at the satellite, and then reconfigure the transaction database from file. For information about reconfiguring a transaction database, see Running Global Projects with PDMS. If the TO database is allocated to other locations, the Recover command should be used to copy the database to all secondary locations.
Examples:
RECONFIGURE
Command Syntax:
>--- RECONfigure ---+---- FORCE ----. | | |--- SESSIONS --| | | --- SAMEREF ---+--->
7.3.70
7:89
12.0
RECOVER PIPEN/PIPEN
Recovers from BBB or DDD, whichever is the most recent.
RECOVER STEELN/STEELN
Recovers from BBB, that is the next DB on the route to the Primary Location
7:90
12.0
System DBs
7.3.71
REINIT (Reconfiguration)
Function: Re-initialises the reference number index. Description: Re-initialises the reference number index in database reconfiguration. Command Syntax:
7:91
12.0
7.3.72
Other than when the REMOTE . . . CHECK command is used, the databases must be primary at the destination Satellite. At Global 12 you can perform Queries on the REMOTE function to allow reporting on session details and other file details for remote satellites. The REMOTE . . . BACKTRACK, REVERT, MERGE CHANGES and EXPUNGE commands can be given at the Hub, the Satellite itself or the administering location. The Satellite itself may need to use the REMOTE version of the command, because it may not have write access to the system database. The administering Location may need to use the REMOTE version of the command, because it may not have write access to the constructor database. The REMOTE . . . CHECK command can be given at any location. Certain REMOTE commands cannot be used for Extract databases - see below. Note: The difference between the REMOTE options, and centralised administration of a satellite, are that REMOTE commands are executed by the Global Daemon, rather than by PDMS. All daemon commands take time to complete, and generally you will need to wait for this to happen. The REMOTE commands (other than CHECK) can only be applied to databases which do not own extracts and to leaf extracts. REMOTE . . . BACKTRACK, MERGE CHANGES and EXPUNGE commands will not take effect while there are users (or potential users, for example, in MONITOR) in the project. REMOTE . . . BACKTRACK will do nothing if the primary location of the database contains later sessions than the secondary database at the issuing location. It will not backtrack through stamped sessions. The database must be allocated at the issuing location in order to determine the latest session there. If the primary database at the satellite contains later sessions than the secondary database at the Location issuing the command, the REMOTE . . . MERGE CHANGES command will not merge the later sessions. (If the database is non-propagating, later sessions will be merged). REMOTEMERGE will not remove Stamped sessions. Unless the database is non-propagating, it must be allocated at the issuing location in order to determine the latest session there. REMOTE MERGE also merges the database at secondary locations after it has been merged at the primary location in order to prevent unnecessary copying of the entire database when it is next updated. This means that the command may take some time to complete.
7:92
12.0
You are advised to stop scheduled updates and avoid adhoc updates until the entire REMOTEMERGE command has completed. If scheduled updates are left in place, then unnecessary copying of entire databases will be undertaken, and changes made by users at the primary location may be lost. The REMOTE . . . CHECK command can be given at any location on any database. Both Primary and Secondary databases can be checked. This command runs standalone DICE on the specified database from the daemon at the specified location and reports back to the location that issued the command. However, extract databases cannot usefully be checked in isolation (using CHECK FILE), since access to the extract owner is required. This means that REMOTE CHECK cannot be used on Extract databases other than the extract master. You can also query information about the project status at a Satellite. See Querying below. REMOTEEXPUNGE cannot distinguish between genuine and dead users of a database at a location. The system administrator should use remote session information (see Querying below) to check which users are actually writing to the database. REMOTEMERGE and REMOTEBACKTRACK are not valid for extracts which own other extracts. However, REMOTEREVERT and REMOTEEXPUNGE can be used. A database that owns extracts can be merged in PDMS using the MERGE command.
Examples: For details of time and date syntax, see Notes on Syntax Graphs. BACKTRACK
REMOTE <loc> BACKTRACK dbname TO 14:30 REMOTE <loc> BACKTRACK dbname TO SESS 17
Backtracks changes to the given database, which must be Primary at the named location. A database cannot be backtracked through a stamp. REVERT
REMOTE <loc> REVERT dbname TO 14:30 REMOTE <loc> REVERT dbname TO SESS 17
Adds a session reverting to the data at the specified session or date. The database must be Primary at the named location. MERGE CHANGES
REMOTE <loc> MERGE CHANGES dbname BEFORE 31 MARCH REMOTE <loc> MERGE CHANGES dbname BEFORE SESSION 9 AFTE R SESSION 4
Merges changes to the given database, which must be Primary at the named location. Stamped sessions will not be removed by the merge.
7:93
12.0
EXPUNGE
DB DB DB DB
Expunges all users or the given user from the given database at the given Location. The database must be primary at the given Location. Username can be the PDMS username or a session number. DICE Checking
Performs a standalone DICE check on the given database at the given Location. The database does not need to be primary at the given Location. The check uses the current MODE, STATISTICS, MAXERRORS and MAXWARNINGS settings. Cancelling commands
7:94
12.0
Command Syntax: For details of <loc> and <when> syntax, see Notes on Syntax Graphs.
>- REMOTE <loc> BACKTRACK dbname TO <when> --> >- REMOTE <loc> REVERT dbname TO <when> --> >- REMOTE <loc> MERGE CHANGES -+- dbname ----------------+-<when>--> | - SYSTEM -+- FOR <loc2> -+--> | | ---------------+--> REMOTE (continued) >- REMOTE <loc> EXPUNGE -+- USER username ----------------------. | | |--------------------------------------| | | - DB --+- dbname -+-- USER username --| | | | | -------------------| | | - SYSTEM -+-- FOR <loc2> -----| | | --------------------+--> >- REMOTE <loc> CHECK --+-- DB dbname ------------------------. | | |-- MISCDB --------------------------| | | |-- COMMDB --------------------------| | | |-- SYSTEMDB dbname -+- FOR <loc2> ---. | | | | ----------------| | | -- GLOBALDB ---------------------------+-->
Related Commands: CANCELCOMMAND, REMOTEMESSAGE, MERGE, REVERT, BACKTRACK, EXPUNGE, CHECK Querying: Remote database session information can be queried using the Q REMOTE command:
Information about remote users of PDMS may be queried using remote session objects. For example: !p = current project !l = !p.locations() Returns a PROJECT object Returns an array of LOCATION objects
7:95
12.0
!r = !l[2].sessions()
Where !l[2] is not the current location, returns an array of SESSION objects
The following return data about a given session: q var !r[1] q var !r[1].module() q var !r[1].user() q var !r[1].mdb(). This may be combined with information about the satellite MDBs to identify users of a database when using REMOTEEXPUNGE. For more information about PML Objects see the Plant Design Software Customisation Reference Manual. Only these three session methods are available for remote sessions.
7.3.73
7.3.74
7:96
12.0
Examples:
REMOVE SERV/AREA-D
Command Syntax: .------------. / | >-- REMove dbname ---*--- dbname --- | --------------------> Related Commands: ADD, REMOVE, CURRENT, DEFER
7.3.75
7:97
12.0
Examples:
7.3.76
REORDER 2 BEFORE 1
Command Syntax: >-- REORDer element_id --+--- BEFore ---. | | --- AFTer ----+-- list_position -->
7.3.77
7:98
12.0
REPAIR - outputs a report and Repairs the database. REPAIR NOCHECK - Repairs the database without a report. REPAIR CHECKONLY - Outputs a report without Repairing the database.
The latter is useful when using ADMIN in READONLY mode, as at a satellite with a secondary system database. Examples:
7.3.78
The file created by REPLICATE SYSTEM can be run as a macro in ADMIN. The REPLICATE SYSTEM command causes ADMIN to scan the System database (and Global database) and output to the named file all the commands necessary to recreate the project structure.
7:99
12.0
In a Global project, the file created contains macros that should be run in two stages: The first stage creates the basic project structure and generates the satellite locations. The macro then terminates. You should then edit the remainder of the file into a new file to be run as a separate macro, which should not be run until satellites have been created and initialised. The second stage allocates databases to satellites and makes the relevant databases primary at satellites. Before you run the macro to recreate the project structure, you must ensure that suitable project variable have been defined. In a Global project, this must include transfer directories for each satellite (for more details, see the TRANSFER command). Note: It is strongly recommended that this is only done in a newly created project, otherwise results could be unpredictable. Examples:
REPLICATE XYZ
Copies all data from the current project directories into directories for a project named XYZ. In a Global project, a new UUID value for the Project is set (stored in ADUUID of /*GL; this is because each project requires a unique value of this attribute. This is used by Global daemons to distinguish between projects at the same location).
REPLICATE F123
In this case the long project identifier (%ABC000ID%) has been specified. This will replicate to the underlying project path of which this variable is associated, i.e the path that %ABC000% maps to. Note: A new UUID value may be queried at /*GL using Q NEWUID. The administrator may use this value to set ADUUID manually if a Global project has been copied externally to PDMS. If ADUUID is left unchanged, there may be data corruption since daemons may send data to the wrong project. The ADUUID attribute is essential to distinguish between Global projects. Each project should have a unique value of ADUUID. This value is what the Global daemon uses to select the correct project. For example if the user copies a project using the file system, rather than by using the REPLICATE command, then the ADUUID attribute in both projects will be the same, and this may cause commands from one Global project to be received by the wrong Global project. It is therefore essential that the PDMS Administrator resets the ADUUID attribute of the project. The NEWUID attribute provides a way to get a new value, since it makes a 'uuidgen' query. The Administrator can then use the result of the NEWUID attribute query to set the ADUUID attribute. Note that NEWUID is not an attribute of the database. It is a pseudo-attribute provided for the purpose of generating a new uid value for ADUUID. /*GL
7:100
12.0
!N=NEWUID ADUUID=$!N
The FILENumbers option maintains the same file numbers. The OVERWRITE option overwrites an existing file of the same name.
7.3.79
RESETXREFS (Reconfiguration)
Function: Controls a partial update of references following a multi-database reconfiguration.
7:101
12.0
Note: This command is normally handled automatically by the upgrade macros supplied with a new version of PDMS. You are advised to consult your AVEVA Solutions Support Engineer before using it. Description: Updates the cross-references listed in a file created by the XREF command. Can be used when upgrading a project from one version of PDMS to the next. Examples:
7.3.80
7:102
12.0
Examples:
7.3.81
7:103
12.0
7.3.82
Examples:
7:104
12.0
7.3.83
SORTALLOCATE
Function: Re-orders database extracts in a database allocation list Description: Re-orders database extracts in a locations allocation list into the correct extract order, so that extract children follow the parent extract. This affects the order in which database updates are sent. Note: This command does not sort the order of unrelated databases. It is up to the system administrator to ensure a sensible order. Examples: Command Syntax: Querying: Related Commands: ALLOCATE, DEALLOCATE, Q DBALL
7.3.84
OVERALL STATISTICS ================== Total no. of entries in Name Table = 111 Total no. of elements checked = 782 Total no. of ref attributes found = 726 Total no. of external references = 0
7:105
12.0
Command Syntax: >--- STATistics ---+--- OFF ----. | | --- ON -----+---> STATISTICS OFF specifies that no statistics are to be gathered during the checking. This is the default.
7.3.85
STATUSSESSION (Querying)
Function: Gives information about your current status and the database to which you have access. Examples: An example of output is shown below.
7.3.86
STOP
Related Commands: FINISH has the same effect Command Syntax:
7:106
12.0
7.3.87
SYNCHRONISE STEELN/STEELN
Synchronise given database at current location with its Primary location.
SYNCHRONISE ALL
Synchronise all databases at current location with their Primary locations.
7:107
12.0
7.3.88
SYSTAT (Querying)
Function: Gives information about users accessing the project. Description: Lists all users who are accessing the project, the modules and databases which they are using, and whether they have Read-only or Read/Write access to the database. It also gives the login id and workstation identifier. You can select what information you want output: see the following examples.
7:108
12.0
PROJECT SAM ============= User HVAC (75d-sg52) Name au (A.User) Host sg52 Entered 14:37 10 Sep Module DESIGN MDB /HVAC DB HVAC/DESI HVAC/PADD HVAC/CATA MASTER/IPECATA ASTER/STLCATA MASTER/HVACCATA MASTER/SUPPCATA MASTER/PADD MASTER/DICT MASTER/PROP MODE RW R R R R R R R R R
User HANGER (3c41-sg107) Name an (A.N. Other) Host sg107 Entered 14:39 10 Sep Module DRAFT MDB /HANGERS DB HANGERS/DESI HANGERS/PADD HANGERS/CATA ASTER/PIPECATA MASTER/STLCATA MASTER/HVACCATA MASTER/SUPPCATA MASTER/PADD MASTER/DICT MASTER/PROP 2 user(s) listed
Thisshows that two users are using Project SAM: User HANGER who is using DRAFT, and has Read/Write access to the Draft database HANGERS/PADD. User HVAC who is using DESIGN, and has Read/Write access to the Design database HVAC/DESI.
MODE R RW R R R R R R R R
In a Global project, there may also be a SYSTEM user running the Globaldaemon module. This shows that the daemon is running.
7:109
12.0
You can restrict the output to information about the user, host, module or MDB as shown in the following examples:
SYS NAME an
Lists the information for the user id an
7.3.89
If a SYSTEMLOC command fails, the previous primary location will normally be recovered automatically. If the recovery fails (for example, the daemon is not running), you can recover the previous Primary location using the command:
7:110
12.0
Offline locations: An offline Location can only be administered by the Hub or the Location itself. Once an offline Location has been initialised, you can only change the administering Location from the Hub to the Location, not from the Location to the Hub. Examples:
7.3.90
7:111
12.0
Examples:
7.3.91
TERM
Terminates alpha file and outputs reports to screen. Thissyntax is equivalent to ALPHA FILE END Command Syntax:
7.3.92
TO (Reconfiguration)
Function: Specifies the destination database for reconfiguration. In a Global Project, the TO NEW option can only be used at the Hub. The TO DB option can only be used at the Primary Location of a database. When reconfiguring the locations own transaction database (using TO DB), the daemon must first be stopped.
7:112
12.0
Examples:
TO DB USERA/DESIGN
Reconfigured data to go to database USERA/DESIGN in current project.
TO DBFILE des008
Reconfigured data to go to specified file (assumes project directory is current directory).
7.3.93
7:113
12.0
at the transfer directory must be set, and the transfer directory must exist and contain the normal project sub-directories. The current location must be either the Hub or an offline location. The location to which the files are transferred must be either the Hub or an offline location. The transfer directory is specified by the environment variable project_loc where project is the 3-character project code and loc is the 3-character identifier of the remote location. For example, in a Project ABC where the Hub is CAM and the offline Satellite is SYD, the following environment variables must be set:
At CAM: At SYD:
ABC_SYD ABC_CAM
TRANSFER TO copies all the Project files to the transfer directory specified by the project_loc variable. The files are then physically transferred by some means (tape, FTP etc.), and read on to the transfer directory specified by the project_loc variable. The System Administrator at the receiving end then uses the TRANSFER FROM command, which updates the Location with the transferred files. Offline Location: Special care should be taken when using CHANGE PRIMARY for an offline location. Before changing the primary location, it is important to ensure that the database at the new primary location is up-to-date. This may be done by using the TRANSFER TO command at the old primary location followed by the TRANSFER FROM command at the new primary location. All users should have left PDMS before this transfer is made. Any subsequent work on the database will be lost, due to the change in primary location. Examples:
TRANSFER TO
loc
Copies all database files at the current location, together with appropriate inter db macro files etc. to the transfer directory specified by the project_loc variable.
7:114
12.0
7.3.94
TREM SJC
Removes user SJC from the current Team. Command Syntax: .-----<------. / | ---*--- userid ---| | --------------+--->
7.3.95
7:115
12.0
Examples:
TTFONT 6 RENUMBER 19
The font ID of font 6 is changed to 19. Font ID 6 becomes free to be re-used.
7.3.96
7:116
12.0
Examples:
UNLOCK
Unlocks all locked databases In a Global Project, the System Administrator at the Hub or at a Satellites administering location can unlock a Project at the Satellite:
UNLOCK AT LON
Unlocks all locked databases at Location LON. Command Syntax:
7.3.97
7:117
12.0
transfer directory - %EXP_ABC% for location ABC. Transfer of other data is described more fully in the Global Management User Guide. Updates of individual databases obey network routing. The database will be synchronised with the database at locations on the route to the primary location; and updated with the database on the route from the primary location to the destination. Both Locations (and any intermediate locations) must be on-line. Examples of updating constructor databases:
7:118
12.0
Command Syntax:
>--- UPDATE ---+--| |--| |--| --dbname ---. | SYSTEM ---| | ALL ------| | GLOBAL ---+--- WITH <loc> --->
7.3.98
UPGRADE (Reconfiguration)
Function: Produces macros to upgrade a project to a new version of PDMS. Examples:
7.3.99
USERADD TO
Function: Add PDMS users to the Window NT authenticated user. Also allows the specified PDMS user to be the default PDMS username for the Windows NT authenticated user.
7:119
12.0
Examples:
Related Commands: LIST AUTHUSER, USERREM/OVE FROM, AUTHUSERREMOVE, CREATE AUTHUSER, AUTHENTICATION
Related Commands: LIST AUTHUSER, USERREM/OVE FROM, AUTHUSERREMOVE, CREATE AUTHUSER, AUTHENTICATION
7.3.101 VB (Reconfiguration)
Function: Gives very brief output for pass 2 reconfiguration.
7:120
12.0
Examples: A short example of very brief output is shown below. Compare with the brief output shown in the BRIEF command.
*** Pass one initiated *** *** Pass one completed *** *** Pass two initiated *** EC LIBY #92/842 =16/2404
(24,90) Warning! library number 242 already exists in the project. Duplicate libraries should not be used in the same MDB EC DEPT #16/805 =16/2408 Phase one complete - starting phase two *** Pass two completed *** ***Reconfiguration Completed 0 Elements were not defined in DDL 0 Elements have been lost 0 Elements are no longer named 3 Attributes were incorrectly defined 0 Elements were not inserted.
Command Syntax:
>--- VB --->
Related Commands: BRIEF, FULL, ERRORS
XREF /REFFILE
Reference number list to be written to file /REFFILE. Command Syntax:
7:121
12.0
7:122
12.0
Prefix The prefix is dependant on the file type, the following options are available. File Type Picture file Final Designer Drawing Marine Hull Drawing Diagram Stencil Template Neutral Format (SVG) Prefix M M D V V V V
A:1
12.0
Ref No The Ref No is dependant on the file type, the following options are available: File type Picture file FD Drawing Marine Hull Drawing Diagram Stencil Template SVG Neutral Format Extract file The extract file number from which the Drawing was saved. Version The version number when the Drawing was saved. Page Prefix The Page number prefix part of the file name is only used when dealing with SVG files. Page No. Number of pages per Schematic Diagram. Only used when dealing with SVG files. File Suffix The file name suffix is dependant on the file type, the following options are available. File type Picture file FD Drawing Marine Hull Drawing Diagram Stencil Template SVG Suffix Pdmsdwg sdb Vdx Vsx Vtx Svg Element Type SHEE,OVER SHEE,OVER SHEE,OVER SCDIAG SCSTEN SCTEMP SCDIAG Database PADD PADD PADD SCHE SCHE SCHE SCHE
A:2
12.0
Drawing files are stored in a folder defined by an environment variable. In the case of Draft drawing files see table below the file is stored in a numbered sub-folder is determined by the database reference (Module 32 of the second component of the reference). File type Picture file FD Drawing Marine Hull Drawing Diagram Stencil Template SVG Suffix {project}PIC {project}DWG {project}DRG {project}DIA {project}STE {project}TPL {project}DIA
The following attributes may be useful at the above elements Q DRFTYP Q DRFILE Q DRFILE (number) List of drawing file types for elements Default drawing file name for element (for SVG files, for highest number file) Drawing file of specification type of element
There are also attributes specific to each element type PICF, PDWGF, DOFIL VISF, NVIEWF Splitting of Folders When the number of files in a folder becomes huge, the performance of the Microsoft Windows file system can suffer. Some folders in the AVEVA PDMS project folder structure are especially susceptible to this negative effect: <project>PIC <project>DWG containing AVEVA PDMS Draft picture files containing AVEVA Final Designer files for SCEE for SCDIAG
These folders have been split by creating 32 subfolders numbered '00', '01', , '31', and the files, that were previously stored in the main folder, now are spread among the subfolders using an algorithm, that guarantees the most even distribution of files. As a result, the number of files in a single subfolder will be significantly lower, improving the file system performance. The formula for determining the subfolder is: subfolder number = DBREF[2] modulo 32 where DBREF[2] is the second element of the DB reference of the picture element. For example: A sheet in the BAS project having the DB reference =15773/4101, extract file number (EXFI) 16, and picture version number (PVNO) 25. The associated picture file path would be:
A:3
12.0
/%BASPIC%/05/M15773-4101-16-25
where the file name itself is built from the DB reference, the EXFI and PVNO attribute values, as in previous versions, but the subfolder number (05) has been derived by the formula:
4101 modulo 32 = 5
Assuming, that the DB references are allocated sequentially, we can then expect an even selection of the subfolder for the picture files. Some features of the implemented algorithm: If the DB reference does not change, the subfolder number also stays the same. Creation of the new version of the picture, or modification of this picture from an extract will change the EXFI or PVNO attribute values, but the reference would stay the same, thus preserving the selected subfolder number. If the picture element is removed, and then later recreated (e.g. from a DATAL transfer), it may get assigned a different DB reference, than originally, thus getting possibly a different subfolder for its picture file.
All existing Admin functions, including purging picture files, copying or deleting DBs, creating or replicating projects, etc., are aware of the new folder structure. In order to facilitate the handling of the subfolders and the files therein, the following pseudo-attributes have been implemented. PICF/ilename PDWGF/ilname DWGF/ilename returns the path to the AVEVA PDMS Draft picture file for the current picture element returns the path to the AVEVA Final Designer file for the current picture element returns the path to the temporary AVEVA Final Designer file for the current picture element
As compared to the folder structure valid for previous versions, the new layout looks as follows:
Figure A:1.
A:4
12.0
Figure A:2.
A:5
12.0
A:6
12.0
Index
A
Attributes non-reference handling of during reconfiguration 3:1, 3:3 reference handling of during reconfiguration 3:1, 3:3
D
Data Integrity Checker (DICE) . . . . . . . . 2:1 DAtaBAse CONtrol program (DABACON) 3:1 Database Description Languages (DDLs) 3:1 Database Structure Elements and their Attributes . . . 4:1, 5:1 Global Database . . . . . . . . . . . . . . . 4:6 Transaction Database . . . . . . . . . . . 5:1 Destination database for reconfigure operations . . . . . 3:1, 3:2 DICE Exiting . . . . . . . . . . . . . . . . . . . . . . . 2:1 Reports . . . . . . . . . . . . . . . . . . . . . . 2:2 Setup Options . . . . . . . . . . . . . . . . . 2:1 Starting up . . . . . . . . . . . . . . . . . . . . 2:1 User Message File . . . . . . . . . . . . . . 2:1 DUMP command . . . . . . . . . . . . . . . . . 3:11
B
Binary-format files . . . . . . . . . . . . . . . . . 3:20 BRIEF command . . . . . . . . . . . . . . . . . . . 3:7 Brief output mode . . . . . . . . . . . . . . . . . . 3:7
C
Character-format files . . . . . . . . . . . . . . 3:20 Commands Detailed Descriptions . . . . . . . . . . . . 7:3 Reconfiguration . . . . . . . . . . . . . . . . 3:2 Summary in Functional Groups . . . . 6:1 Syntax Graphs . . . . . . . . . . . . . 7:1, 7:2 Communications elements LCOMC (Admin Daemon Config) . . . 4:3 LCOMD (Comms Link Details) . . . . . 4:4 LCOML (LCOMD Elements List) . . . 4:3 LCTIMD (Event Timings) . . . . . . . . . 4:6 LCTIML (Event Timer) . . . . . . . . . . . 4:5 LEVENL (Time Interval) . . . . . . . . . . 4:5 Copies of databases . . . . . . . . . . . . . . . . 3:8 Copy list (for reconfiguration) . 3:2, 3:4, 3:11
E
Elements DB (Database) . . . . . . . . . . . . . . . . . 4:8 DBALL (Location DB List) . . . . . . . 4:13 DBLI (Database List) . . . . . . . . . . . . 4:8 DBLOC (DB Location) . . . . . . . . . . . 4:9 GRP (Group) . . . . . . . . . . . . . . . . . 4:11 GRPLI (Group List) . . . . . . . . . . . . 4:11 LNK (Links) . . . . . . . . . . . . . . . . . . 4:14 LNKLI (Link List) . . . . . . . . . . . . . . 4:13 LOC (Location) . . . . . . . . . . . . . . . 4:11 LOCLI (Location List) . . . . . . . . . . . 4:11 PEROP (Perops) . . . . . . . . . . . . . . 4:10 ROLE (Role) . . . . . . . . . . . . . . . . . . 4:9 TEAM (Team) . . . . . . . . . . . . . . . . . 4:7
Index page 1
12.0
Errors reconfiguration controlling limit of for output . . . . 3:8 ERRORS command . . . . . . . . . . . . . . . . 3:8
R
RCFCOPY command . . . . . . . . . . . . . . . 3:4 RCFUPDATE command . . . . . . . 3:10, 3:11 Reconfiguration . . . . . . . . . . . . . . . . . . . 3:5 Extracts . . . . . . . . . . . . . . . . . . . . . 3:21 Projects . . . . . . . . . . . . . . . . . . . . . 3:20 same references . . . . . . . . . . . . . . . 3:5 Transaction Database . . . . . . . . . . 3:24 RECONFIGURE command . . . . . . . . . . 3:4 RECONFIGURER . . . . . . . . . . . . . . . . . 3:1 Reference attributes . . . . . . . . . . . . 3:9, 3:10 Reference number index . . . . . . . . . . . 3:10 listing . . . . . . . . . . . . . . . . . . . . . 3:5, 3:7 loading from file . . . . . . . . . . . . . . . 3:11 saving to file . . . . . . . . . . . . . . . . . . 3:11 References between databases . . . . . . . . . . . . . 3:9 Relevant User Guides . . . . . . . . . . . . . . 1:1 REPLICATE command . . . . . . . . . . . . . 1:1 RESETXREFS command . . . . . . . . . . 3:14 Root element . . . . . . . . . . . . . . . . . . . . 3:11
F
FROM command . . . . . . . . . . 3:3, 3:13, 3:20 FULL command . . . . . . . . . . . . . . . . . . . 3:7 Full output mode . . . . . . . . . . . . . . . . . . . 3:7
G
Global Commands . . . . . . . . . . . . . . . . . 1:1 Groups reconfiguring . . . . . . . . . . . . . . . . . . 3:13
I
INCLUDE command . . . . . . . . . . . . . . . 3:11 Index of reference numbers . . . . . . . . . . . 3:10 Intermediate files . . . . . . . . . . . . . . . 3:1, 3:3 Isodraft files . . . . . . . . . . . . . . . . . 4:5, 7:117
S
SAMEREF option . . . . . . . . . . . . . . . . . . 3:5 Source database for reconfigure operation . . . . . . 3:1, 3:2
L
LOAD command . . . . . . . . . . . . . . . . . . 3:11
M
Manual Content . . . . . . . . . . . . . . . . . . . . 1:1 Messages . . . . . . . . . . . . . . . . . . . . . . . 3:17
T
TO command . . . . . . . . . . . . 3:4, 3:13, 3:20 Transaction elements TRDAY (Command Date Day) . . . . . 5:3 TRFAIL (Transaction Failure) . . . . 5:11 TRFLST (Transaction Failure List) 5:11 TRINCO (Transaction Incoming Command) 5:3 TRLOC (Transaction Location) . . . . 5:3 TRMESS (Transaction Message) . 5:11 TRMLST (Transaction Messages List) 5:11 TRMONT (Command Date Month) . 5:3 TROPER (Transaction Operation) . . 5:9 TROUCO (Transaction Output Command) 5:6 TRSLST (Transaction Success List) 5:11 TRSUCC (Transaction Success) . . 5:11 TRUSER (Transaction User) . . . . . . 5:3 TRYEAR (Command Date Year) . . . 5:3
O
Offline location 4:5, 4:11, 6:3, 7:8, 7:16, 7:17, 7:27, 7:37, 7:49, 7:55, 7:56, 7:58, 7:76, 7:79, 7:107, 7:111, 7:114 Output controlling . . . . . . . . . . . . . . . . . . . . . 3:7
P
PADD databases treatment of when reconfiguring . . . 3:12 Picture files treatment of when reconfiguring . . . 3:12 Plot files . . . . . . . . . . . . . . . . . . . 4:5, 7:117 Programmable Macro Language (PML) . 1:1 Projects transferring data between . . . . . . . . 3:13 upgrading . . . . . . . . . . . . . . . . . . . . 3:14
U
Upgrade macros . . . . . . . . . . . . . . . . . . 3:15
Index page 2
12.0
V
VB Command . . . . . . . . . . . . . . . . . . . . . 3:7 Very Brief output mode . . . . . . . . . . . . . . 3:7
W
World elements GLOCWL (Global Location) . . . . . . 4:10 GROWL (Global Role) . . . . . . . . . . . 4:9 GSTAT (Global Status) . . . . . . . . . . 4:7 GSTWLD (Global Stamp) . . . . . . . . 4:14 GTMWL (Global Team) . . . . . . . . . . 4:7 LCOMW (Communications) . . . . . . . 4:3 STAT (Project Status) . . . . . . . . . . . 4:3 TRMSGW (Transaction Message) . . 5:2
X
XREF command . . . . . . . . . . . . . . . . . . 3:14
Index page 3
12.0