Pdms Admin: Command Reference Manual

PDMS ADMIN
Command Reference Manual

Version 11.5
PDMS1151/man17/doc1
Issue 140403
PLEASE NOTE:
AVEVA Solutions has a policy of continuing product development: therefore, the
information contained in this document may be subject to change without notice.
AVEVA SOLUTIONS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO
THIS DOCUMENT, INCLUDING BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE.
While every effort has been made to verify the accuracy of this document, AVEVA
Solutions shall not be liable for errors contained herein or direct, indirect, special,
incidental or consequential damages in connection with the furnishing, performance or
use of this material.
This manual provides documentation relating to products to which you may not have
access or which may not be licensed to you. For further information on which Products
are licensed to you please refer to your licence conditions.
 Copyright 1991 through 2003 AVEVA Solutions Limited

All rights reserved. No part of this document may be reproduced, stored in a retrieval
system or transmitted, in any form or by any means, electronic, mechanical,
photocopying, recording or otherwise, without prior written permission of AVEVA
Solutions.
The software programs described in this document are confidential information and
proprietary products of AVEVA Solutions or its licensors.
For details of AVEVA's worldwide sales and support offices, see our website at
http://www.aveva.com
AVEVA Solutions Ltd, High Cross, Madingley Road, Cambridge CB3 0HB, UK
Revision History
Date Version Notes

March 2003 11.5 Section 4 First note moved to Section 3.19.8 and updated
Figure 4-2 LCOML element title changed and LCOMD
element added
Section 4.2.1 LCTIML element updated
Section 5.5 Second para added
Section 7 ALLOCATE Updated for offline locations,
OVERRIDE PROPG and related commands
Section 7 CHANGE Updated for offline locations and related
commands
Section 7 CREATE Updated description about extracts, note
about offline locations, and built-in recovery
Section 7 DELETED Note added about deleted files
Section 7 EXTRACT Updated to cover FLUSH RESET
Section 7 GENERATE Sentence about Hub added to second
para of description
Section 7 HUB LOCATION Description updated to cover
OVERRIDE PROPG
Section 7 NEW Additional example for Global
Section 7 PREVOWNER updated to cover built-in recovery

Section 7 QUERY Updated to include attributes for database
states
Section 7 RECOVER Minor change to note in description
Section 7 REMOTE Function updated for BACKTRACK,
CHANGES and MERGE
Section 7 RENEW updated to cover DELETE option

Section 7 TO Function updated to mention stopping daemon
Section 7 TRANSFER Description updated to cover offline
location
Index - All occurrences of offline location references included
VANTAGE PDMS ADMIN

Version 11.5
AVEVA Solutions Ltd, High Cross, Madingley Road, Cambridge CB3 0HB, UK
Contents
1 Introduction ................................................................................................... 1-1
1.1 Macros .........................................................................................................................1-1
1.2 How to Use This Manual............................................................................................1-2
2 Stand-Alone DICE.......................................................................................... 2-1
2.1 DICE Errors................................................................................................................2-1
2.2 DICE Commands ........................................................................................................2-2
3 Reconfiguration............................................................................................. 3-1
3.1 The Reconfiguration Process......................................................................................3-1
3.2 Starting up RECONFIGURER ..................................................................................3-2
3.3 Administrative and Querying Commands ................................................................3-2
3.4 Basic Reconfiguration ................................................................................................3-3
3.4.1 Reconfiguring a Single Database .....................................................................3-3
3.4.2 Specifying the Source Database .......................................................................3-3
3.4.3 Specifying the Destination DB .........................................................................3-4
3.4.4 Specifying What Will be Copied .......................................................................3-4
3.4.5 Starting the Reconfiguration Process ..............................................................3-5
3.4.6 Example of a Simple Reconfiguration ..............................................................3-5
3.5 Using the SAMEREF Option .....................................................................................3-6
3.6 Using the SESSIONS Option.....................................................................................3-6
3.7 Listing the Reference Number Index ........................................................................3-7
3.8 Global Projects............................................................................................................3-8
3.9 Controlling RECONFIGURER Output .....................................................................3-8
3.10 Copies and Reconfigured Copies of DBs....................................................................3-9
3.10.1Copies………….. ...............................................................................................3-9
3.10.2Reconfigured Copies.........................................................................................3-9
3.11 Advanced Reconfiguration .......................................................................................3-10
3.11.1References Between Databases .....................................................................3-10
3.11.2Updating References into a Reconfigured Database ....................................3-11
3.11.3Saving the Reference Number Index ............................................................3-12
3.11.4Copying Parts of Databases...........................................................................3-12
3.11.5Copying Groups ..............................................................................................3-14
3.12 Transferring Data Between Projects.......................................................................3-14
3.13 Upgrading a Project..................................................................................................3-15
3.14 Reconfiguration Messages........................................................................................3-18
3.14.1Standard Information Messages ...................................................................3-19
3.14.2General Format of Pass 2 Error Messages ...................................................3-19
3.14.3Codes Used to Identify Message Types.........................................................3-20
3.15 Database Transfers between Computers ................................................................3-20
3.16 Binary and Character Files .....................................................................................3-21
3.17 The Transfer Process................................................................................................3-21
3.18 Reconfiguring a Global Project ................................................................................3-22
VANTAGE PDMS ADMIN Contents-i

Version 11.5
Contents
3.19 Reconfiguring Extracts ............................................................................................ 3-22

3.19.1Outputting Changes Only ............................................................................. 3-22
3.19.2RECONFIG SAMEREF FULLThe SAMEREF Option ............................... 3-22
3.19.3The SESSIONS Option ................................................................................. 3-22
3.19.4Reconfiguring a Single Extract..................................................................... 3-23
3.19.5Reconfiguring a Family of Extracts.............................................................. 3-23
3.19.6The RCFUPDATE command ........................................................................ 3-24
3.19.7Example of Reconfiguring a Three Level Extract........................................ 3-24
3.19.8Reconfiguring the Transaction Database in a Global Project ..................... 3-26
4 The System and Global Databases ............................................................. 4-1
4.1 Standard Projects: the System Database ................................................................. 4-1
4.2 Global Projects ......................................................................................................... 4-10
4.2.1 Structure of the Local System Database ....................................................... 4-12
4.2.2 Structure of the Global Database .................................................................. 4-15
5 The Transaction Database ........................................................................... 5-1
5.1 Structure of the Transaction Database .................................................................... 5-1
5.2 TRMSGW element ..................................................................................................... 5-3
5.3 TRYEAR, TRMONT and TRDAY elements ............................................................. 5-3
5.4 TRUSER and TRLOC elements ................................................................................ 5-3
5.5 TRINCO element (Input Command)......................................................................... 5-4
5.6 TROUCO element (Output Command)..................................................................... 5-7
5.7 TROPER element (Operation)................................................................................. 5-10
5.8 TRMLST, TRSLST, and TRFLST elements ........................................................... 5-11
5.9 TRMESS, TRSUCC, and TRFAIL elements .......................................................... 5-12
6 Command Summary ..................................................................................... 6-1
6.1 Project Definition ....................................................................................................... 6-1
6.2 Project Administration .............................................................................................. 6-2
6.3 Global Project Administration .................................................................................. 6-2
6.4 Module Definition ...................................................................................................... 6-3
6.5 Font Definition........................................................................................................... 6-3
6.6 Querying..................................................................................................................... 6-3
6.7 General PDMS Commands........................................................................................ 6-4
6.8 Data Integrity Checking............................................................................................ 6-4
6.9 Reconfiguration.......................................................................................................... 6-4
7 Command Details.......................................................................................... 7-1
7.1 Conventions Used in the Syntax Graphs.................................................................. 7-1
7.2 Notes on Syntax Graphs............................................................................................ 7-3
7.3 Detailed Descriptions of Commands......................................................................... 7-4
ACCESS (Project definition)..................................................................................... 7-5
ACRADD (Project definition).................................................................................... 7-6
ACRREM (Project definition) ................................................................................... 7-7
ADD (Project definition) ........................................................................................... 7-8
ADMINISTER (Global Project Administration - Remote Administration)............ 7-9
ALLOCATE (Global Project Administration - Hub only) ..................................... 7-12
Contents-ii VANTAGE PDMS ADMINlt

Version 11.5
Contents
ALPHA (General PDMS Command) ......................................................................7-15

BACKTRACK (Project Administration) .................................................................7-16
BRIEF (Reconfiguration) ........................................................................................7-18
CANCELCOMMAND (Global Project Administration) ........................................7-19
CDESC (Project definition) .....................................................................................7-20
CHANGE (Project definition)..................................................................................7-21
CHECK (Data Integrity Checking) .........................................................................7-25
CHECKOPTION (Data Integrity Checking) ..........................................................7-28
CNAME (Project definition) ....................................................................................7-32
COPY (Project definition)........................................................................................7-34
CREATE (Project definition)...................................................................................7-36
CURRENT (Project definition) ...............................................................................7-43
DADD (Project definition) .......................................................................................7-44
DEALLOCATE (Global Project Administration - Hub only) ................................7-45
DEFER (Project definition) .....................................................................................7-47
DELETE (Project definition)...................................................................................7-48
DREMOVE (Project definition)...............................................................................7-51
DUMP (Reconfiguration) ........................................................................................7-52
DUPLICATENAMES (Global Project Administration).........................................7-53
EDIT (Module definition)........................................................................................7-55
ERRORFILE (Data Integrity Checking).................................................................7-57
ERRORS (Reconfiguration).....................................................................................7-58
EXCHANGE (Project definition) ............................................................................7-59
EXCLUDE (Project definition)................................................................................7-60
EXPUNGE (Project administration) ......................................................................7-61
EXTERNAL (Data Integrity Checking) ..................................................................7-63
EXTRACT (Project administration) .......................................................................7-65
FINISH (General PDMS Command)......................................................................7-68
FONTDIRECTORY (Font definition) .....................................................................7-69
FONTFAMILY (Font definition) ............................................................................7-70
FROM (Reconfiguration).........................................................................................7-72
FULL (Reconfiguration) ..........................................................................................7-73
GENERATE (Global Project Administration - Hub only) .....................................7-74
GETWORK (General PDMS Command)................................................................7-76
HUBLOCATION (Global Project Administration - Hub only)..............................7-77
INCLUDE (Project definition) ................................................................................7-79
INITIALISE (Global Project Administration)........................................................7-80
ISOLATION (Global Project Administration) .......................................................7-81
LIST (Querying).......................................................................................................7-82
LOAD (Reconfiguration) .........................................................................................7-85
LOCK (Project administration) ..............................................................................7-86
MAKE GLOBAL (Global Project Administration).................................................7-87
MAXERRORS (Data Integrity Checking)...............................................................7-88
MAXUSERS (Project Administration) ...................................................................7-89
MAXWARNINGS (Data Integrity Checking) .........................................................7-90
MERGE CHANGES (Project Administration).......................................................7-91
MESSAGE (Project administration).......................................................................7-94
MODE (Data Integrity Checking) ...........................................................................7-95
VANTAGE PDMS ADMIN Contents -iii

Version 11.5
Contents
MODULE (Module Definition) ............................................................................... 7-96

MOVE (Project administration) ............................................................................. 7-98
NEW (Project definition and Global Project Administration) .............................. 7-99
NEW STAMP (Project administration) ............................................................... 7-101
PING (Global Project Administration) ................................................................ 7-103
PREVOWNER (Global Project Administration - Hub only) ............................... 7-104
PROJECT (Project definition) .............................................................................. 7-106
PURGE (Project Administration and Global Project Administration) .............. 7-108
QUERY (Querying) ............................................................................................... 7-109
RCFCOPY (Reconfiguration)................................................................................ 7-114
RCFUPDATE (Reconfiguration) .......................................................................... 7-116
RCFUPGRADE (Reconfiguration) ....................................................................... 7-117
RECONFIGURE (Reconfiguration) ..................................................................... 7-118
RECOVER (Global Project Administration)........................................................ 7-120
REINIT (Reconfiguration) .................................................................................... 7-123
REMOTE (Global Project Administration).......................................................... 7-124
REMOTEMESSAGE (Global Project Administration) ....................................... 7-130
REMOVE (Project definition) ............................................................................... 7-131
RENEW (Global Project Administration)............................................................ 7-132
REORDER (Global Project Administration) ....................................................... 7-134
REPLICATE (Project definition).......................................................................... 7-135
RESETXREFS (Reconfiguration)......................................................................... 7-138
REVERT (Project administration) ....................................................................... 7-139
SAVEWORK (General PDMS Command) ........................................................... 7-140
SET (Project definition and Global Project Administraion) ............................... 7-141
STATISTICS (Data Integrity Checking) .............................................................. 7-142
STATUSSESSION (Querying) ............................................................................. 7-143
STOP (Data Integrity Checking) .......................................................................... 7-144
SYNCHRONISE (Global Project Administration) .............................................. 7-145
SYSTAT (Querying) .............................................................................................. 7-147
SYSTEMLOCATION (Global Project Administration - Hub Only) ................... 7-150
TADD (Project definition) ..................................................................................... 7-152
TERM (General PDMS Command)...................................................................... 7-153
TO (Reconfiguration) ............................................................................................ 7-154
TRANSFER (Global Project Administration)...................................................... 7-156
TREMOVE (Project definition)............................................................................. 7-158
UNLOCK (Project administration) ...................................................................... 7-159
UPDATE (Global Project Administration) .......................................................... 7-160
UPGRADE (Reconfiguration)............................................................................... 7-162
VB (Reconfiguration) ............................................................................................ 7-163
XREF (Reconfiguration) ....................................................................................... 7-164
Index ...........................................................................................................................1
Contents-iv VANTAGE PDMS ADMINlt

Version 11.5
1 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
VANTAGE PDMS 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 VANTAGE Plant Design
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 Plant Design 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 VANTAGE Plant Design Software Customisation
Guide and the VANTAGE Plant Design Software Customisation Reference Manual.
VANTAGE PDMS ADMIN 1-1

Version 11.5
Introduction
1.2 How to Use This Manual
Chapter 2, Stand-Alone DICE, applies to Standard and Global projects and describes
how to run the PDMS Data Integrity Checker, DICE, from outside PDMS. This chapter
is included in the Command Reference manual as there is no interface to stand-alone
DICE, and you will need to enter commands interactively or via a macro.
Chapter 3, Reconfiguration, applies to Standard and Global projects and describes
database reconfiguration.
Chapter 4, The System and Global Databases , 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.
Chapter 5, The Transaction Database applies to Global projects only, and describes the
transaction database, the elements in it, and their attributes.
Chapter 6, Command Summary applies to Standard and Global projects. It lists the
ADMIN commands in functional groups.
Chapter 7, 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.
1-2 VANTAGE PDMS ADMIN

Version 11.5
2 Stand-Alone DICE
The PDMS Data Integrity Checker (DICE) can be run as a stand-alone program outside
PDMS. This may be necessary if the System database has been corrupted, and you
cannot 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 6, 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.

Version 11.5
Stand-Alone DICE
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
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.

Version 11.5
3 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 VANTAGE PDMS ADMIN User Guide.
3.1 The 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.

Version 11.5
Reconfiguration
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:
proj ABC
user SYSTEM/XXXXXX
admin
You can now start to set up the reconfiguration parameters using the commands
summarised in the Command Summary under Reconfiguration.
3.3 Administrative and Querying Commands

Some of the general PDMS and querying commands, which are particularly relevant to
reconfiguration, are summarised below.
SYSTAT Gives information about the current active status of the project
within which you are working.
LIST Lists project information; there are a variety of options.
SET TEAM Sets the specified team as the current one.
LOCK, UNLOCK Locking the System Database prevents any new users entering
the project.
MESSAGE Sends messages to other users.
Q DB Gives the type, number and filename of the specified DB, and a
list of the MDBs of which it is a member. For example:
Q DB CIVIL/JBX37C
CIVIL/JBX37C DESI NUMBER 6 FILENAME /TVX000/TVX009
MDBS: /LAYOUT /TANKS
Q COPIES Lists all DBs which are copies of the specified DB. For example:
Q COPIES CIVIL/JBX37C
DB CIVIL/JBX37C HAS COPIES:
CIVIL/JBX47C
Q MDB Lists the DBs in the specified MDB.
Q TEAM Lists the users who are members of the specified team, plus a list
of the DBs owned by the team.
Q SET TEAM Gives the name of the currently set team, if any.
Q LOCK Shows whether the project is locked.

Version 11.5
Reconfiguration
3.4 Basic Reconfiguration
3.4.1 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.
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.
PASS 2 - Phase 1 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.
PASS 2 - Phase 2 The second intermediate file is read and its contents used to set
all reference attributes in the destination DB and to perform
insertion operations.
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 Specifying the Source Database

The source of the data to be copied is specified using the FROM command. Some
examples of the use of FROM are:
FROM DB STEELS/STEELS
Source data is in database STEELS/STEELS in current project

Version 11.5
Reconfiguration
FROM PROJECT XXX STEELS/STEEL

Source data is in specified DB in project XXX
FROM DBFILE /abc016

Source data is in specified file (assumes project directory is current
directory)
3.4.3 Specifying the Destination DB

The destination of reconfigured data is specified using the TO command. Some examples
of the use of TO are:
TO DB STEELS/STEELS
Reconfigured data to go to database STEELS/STEELS in current project
TO NEW HVAC/HVAC DBNO 777

Reconfigured data to go to new database USERM/DESIGN, number 777, 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 is 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 Section 3.11.4, 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
Section 3.10, Copies and Reconfigured Copies of DBs.
Note: The new database will need to be added to the appropriate MDBs.
3.4.4 Specifying What Will be Copied

The RCFCOPY command specifies which parts of the source DB are to be copied to the
destination. Most commonly a whole DB is reconfigured, using the command option
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.

Version 11.5
Reconfiguration
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 Starting the Reconfiguration Process

The reconfiguration process is started by giving the command:
RECONFIGURE (minimum abbreviation RECON)
Messages are output to indicate the successful start and completion of each stage. When
the process is complete, all information concerning the source, destination, copy list and
the 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 Section 3.5, Using the SAMEREF Option, for details.
• Use the SESSIONS option to ensure that the session information stays the same
after reconfiguration. See Section 3.6, Using the SESSIONS Option for details.
3.4.6 Example of a Simple Reconfiguration

The following command sequence might be used to reconfigure a DB which is not
referenced by any other DBs:
FROM DB MASTER/DESIGN
TO DB MASTER/DESNEW
RCFCOPY ALL
RECONFIGURE
Note: In practice it would be advisable to use RCFUPDATE and DUMP in the
command sequence. See Sections 3.11.2 and 3.11.3.
The following messages are typical of the output during a completely successful
reconfiguration:

Version 11.5
Reconfiguration
*** 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 Section 3.14, Reconfiguration Messages, for a complete list of output messages.
3.5 Using the SAMEREF Option
When a DB is reconfigured, the reference numbers of the elements in the destination DB

will be different from the corresponding reference numbers in the source DB. To ensure
that 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:
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 Using the SESSIONS Option
When a DB is reconfigured, by default the session information from the source DB is not
preserved. To ensure that session information such as the original session comment,

Version 11.5
Reconfiguration
session number, username and original date stays the same after reconfiguration, you
can use the command:
RECONFIGURE SESSIONS
The option is not valid for SYSTEM, GLOBAL or COMPARATOR DBs, and is not
available for a partial reconfiguration.
The following example illustrates the use of the SESSIONS option:
FROM DB CTBATEST/DESI
TO FILE /A /B
RCFCOPY ALL
RECONFIG SESSIONS
After reconfiguration, data can be read back in from the file using the existing
commands, replacing the original DB data. When reading in data, the DB number and
extract number must be the same as the originating DB number and extract number.
For example:
FROM FILE /A /B
TO DB CTBATEST/DESI
RECONFIG
The SAMEREF option is assumed when reading the data. If errors occur, the data is not
saved. If you want the data saved even if errors occur, use the FORCE option. For
example:
FROM FILE /A /B
TO DB CTBATEST/DESI
RECONFIG FORCE
3.7 Listing the Reference Number Index
When a DB is reconfigured without the SAMEREF option, the reference numbers of the
elements in the destination DB will be different from the corresponding reference
numbers in the source DB.
An index of the reference numbers of elements in the new DB against those in the old
DB is automatically created as an essential part of the reconfiguration process. The new
reference corresponding to an old reference can be queried using the command:
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

Version 11.5
Reconfiguration
3.8 Global Projects

In a Global project, you can reconfigure the System and Global databases. The
commands are:
FROM SYSTEM
RECONFIGURE
(The above command also works in a non-Global project.)
FROM GLOBAL
RECONFIGURE
In both these cases, the existing System or Global databases will be overwritten, so you
do not give a TO command. The COPY ALL and SAMEREF options are also implied.
In a Global project, you can only give a RECONFIGURE command for a System or Global
database if you are at the primary location of the database:
• For a Global database, the primary location is the Hub.
• For a Satellite System database, the primary location may be at the Satellite itself,
or it may be at another Satellite, or at the Hub. The RECONFIGURE command
reconfigures the currently open System database. At a Satellite, the command can
therefore operate either on the local System database, or on another Satellite’s
System database which is primary at the local Satellite.
3.9 Controlling RECONFIGURER Output
You can control the format and extent of the output produced by RECONFIGURER
during Pass 2 processing. The commands are:
VB very brief output mode
BRIEF brief output mode
FULL 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.
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

Version 11.5
Reconfiguration
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 Copies and Reconfigured Copies of DBs
There are two ways of copying a DB in PDMS, which create two different types of copy:
copies and reconfigured copies. This section explains the difference.
3.10.1 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.
RCFCOPY PIPEA/PIPEA ADMIN/TEST
The key features of copies are:
• All copies of DBs have the same DB number. This may be seen by using the LIST
FILES command. For example:
MASTER/DES DESI NUMBER 14 FILENAME /%DRA000%/dra013 UPDATE
PIPEA/PIPEA DESI NUMBER 2 FILENAME /%DRA000%/dra001 UPDATE
ADMIN/TEST DESI NUMBER 2 FILENAME /%DRA000%/dra003 UPDATE
USER/DRAFT PADD NUMBER 5 FILENAME /%DRA000%/dra004 UPDATE
• 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:

Version 11.5
Reconfiguration
• A reconfigured copy has a different DB number from that of the source DB.
• 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 References Between Databases

A DB often contains elements which have reference or reference array attributes which
point into other DBs. For example, one Design DB could contain a Branch connected to a
Nozzle in another Design DB. The HREF (or TREF) attribute of the Branch would point
into the second DB and the CREF attribute of the Nozzle would point back into the first
DB. See example below:
HREF /E1-N2 Branch /150-B1
DESIGN DB 1
CREF /150-B1
Nozz /E1-N2
DESIGN DB 2

Version 11.5
Reconfiguration
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.11.2 Updating References into a Reconfigured Database

While a DB is being reconfigured without the SAMEREF option, RECONFIGURER
builds up an index of the reference numbers of all elements in the source DB versus
their corresponding new reference numbers in the destination DB. The RCFUPDATE
command uses this index to check reference pointers in other DBs and update them to
point to the correct elements in the reconfigured DB. Examples of the use of this
command are:
RCFUPDATE DB MASTER/DESIGN
Updates references to the reconfigured DB from DB MASTER/DESIGN.
RCFUPDATE MDB /USERA
Updates all references to the reconfigured DB from DBs in MDB /USERA.
RCFUPDATE TEAM USER
Updates all references to the reconfigured DB from DBs owned by team USER.
Notes:
The RCFUPDATE command must be given immediately following a RECONFIGURE
operation.
As the RCFUPDATE command may cause a DB to be written to, you must have Read-
Write access to all relevant DBs. The DBs must not be in active use by any other user
of the project.
Care should be taken when reconfiguring to the same DB number. If you update a
DB twice, the resulting reference numbers could be wrong. For example:
Old reference New reference
/VESS1 =123/456 =123/457
/VESS2 =123/457 =123/458

Version 11.5
Reconfiguration
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.11.3 Saving the Reference Number Index

The RCFUPDATE command is usually given immediately after databases have been
reconfigured. The index can be saved to a file when the reconfiguration has been
completed; to be used at a later date.
The commands are DUMP to save to a file, and LOAD to load a file. For example:
LOAD /DUMP1
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 cross-
reference 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 Copying Parts of Databases

The RCFCOPY ALL command copies all the elements in the source DB World into the
destination DB World. If the World of the destination DB already contains members,
then the elements from the source DB are added to these.
The RCFCOPY command can be used to define the root elements to be copied. A root
element is any element owned by the World, that is:
BLTA CASW CATA CCTA CMPW CONW DEPT
GPWL LIBY MATW RUNW SITE SPWL UNIT UWRL
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.

Version 11.5
Reconfiguration
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:
RCFCOPY /SITE-A SITE-7
Elements of any other types will be copied into the destination DB as NULL elements,
that is they will be created as floating elements, not owned by any higher-level element.
This does not mean that they are inaccessible. As long as such an element is named (or
you know its new reference number) it can be incorporated as a member of any suitable
parent element by using the INCLUDE command.
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:
RCFCOPY /ZONE5A INTO /SITE-3
would copy the Zone /ZONE5A and make it the last member of the Site /SITE-3.
If the intended owning element does not already exist in the destination DB at the
beginning of Pass 2, the listed root element will not be copied. For example:
RCFCOPY /SITE-3 /ZONE5A INTO /SITE-3
is not allowed.
INTO cannot be used when the destination is FILES rather then a DB. The word AND
and the comma (,) may be used as separators to improve readability, thus:
RCFCOPY /SITE-5, /ZONE5A INTO /SITE-3, /SITE-6 AND /SITE-12
Several RCFCOPY commands can be given in sequence to add elements to the copy list.
For example, the sequence
RCFCOPY /SITE-5
RCFCOPY /ZONE5A INTO /SITE-3
RCFCOPY /SITE-6, /SITE-12
is exactly equivalent to the RCFCOPY command in the previous example.
If an element is quoted in the copy list but does not exist in the source DB, an error
message is output and the element is not copied. Since RCFCOPY commands are
additive, a correcting command may be given on the next line. For example:
RCFCOPY /SITE1 /SITE2 /SITR3 /SITE4
(24,16) /SITR3 not found (error message)
Since SITE1, SITE2 and SITE4 are already in the copy list, all that is needed to add
SITE3 is:
RCFCOPY /SITE3
Note: Partial reconfiguration of PADD DBs is only allowed for picture elements (i.e.
SHEE, BACK, OVER, SYLB, LALB) and above.

Version 11.5
Reconfiguration
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 Transferring Data Between Projects
RECONFIGURER provides a simple means of transferring data from one project to

another, on the same type of computer, provided both projects are running under the
same major version of PDMS and provided cross-referencing between DBs is considered
logically.
The transfer operation in this case requires the use of the FROM FILES and TO FILES
options of the FROM and TO commands. In the simplest case, namely the transfer of the
contents of a single DB, such as a Catalogue, the following sequence of commands could
be used:
In the source project:
FROM DB /CATOLD Specify source DB.
TO FILES /TEMP1 /TEMP2 Only pass 1 of reconfiguration to be
carried out; partially reconfigured
data to be stored in named files.
RCFCOPY ALL
RECONFIGURE
and in the destination project:
FROM FILES /TEMP1 /TEMP2 Partially reconfigured data to be
recovered from named file;
TO DB /CATNEW pass 2 of reconfiguration to be done.
RCFCOPY ALL
RECONFIGURE
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 Elements Transferred Destination DB
CIVIL/STRUC4 Whole Design DB STEEL/MAIN
ANSI/MASCAT Whole Catalogue DB CATAL/MAIN
SITE-A One Site EQUIP/MAIN
The reconfiguration commands should be given in the following order:
In the source project:

Version 11.5
Reconfiguration
FROM DB ANSI/MASCAT
TO FILES /REC1A /REC1B
RCFCOPY ALL
RECONFIGURE Copies the Catalogue DB first
FROM DB CIVIL/STRUC4
RCFCOPY ALL
RECONFIGURE Copies the Design DB
FROM DB VESSEL/V25CT
RCFCOPY /SITE-A
RECONFIGURE Copies the Site
and in the destination project:
FROM FILES /REC1A /REC1B
TO DB CATAL/MAIN
RECONFIGURE Creates Catalogue DB
TO DB STEEL/MAIN
RECONFIGURE Creates Design DB
TO DB EQUIP/MAIN
RECONFIGURE Creates equipment item
RCFUPDATE DB STEEL/MAIN
RCFUPDATE DB EQUIP/MAIN Gives correct cross-references
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 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
multi-DB 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.

Version 11.5
Reconfiguration
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:
RESETXREFS WITH /REFFILE RESOLVE DB MASTER/DESNEW
RESET /REF2 RESOL /NEWDB
Here /REFFILE is the name of the file generated by the XREF command and
MASTER/DESNEW is the corresponding DB to be updated.
In effect the RESETXREFS command opens the specified XREF file and the RESOLVE
command part initiates the appropriate update. The macro files generated by the
UPGRADE command in ADMIN ensure that the RESET filenames are correctly
matched to the corresponding RESOLVE dbnames.
Note: The XREF file only indicates those elements which need to be updated. The
DUMP files are still required in order to match the old and new reference
numbers correctly.
When reconfiguring a whole project, it is impossible to order databases of the same type
so that all references are resolved as the reconfiguration proceeds. The XREF and
RESETXREFS commands are needed to tidy up the references.
Note: The UPGRADE command is used when a project is being upgraded from an
earlier version of PDMS.
The following is an example of a sequence of commands:
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 ’

Version 11.5
Reconfiguration
Write ’Input phase ’

$R6
Checkddl is 11
To db STANA/SAPROP
From files /REC1A /REC1B
Xref /REC1X
Reconfigure
To db DEREKF/DFPROP
Xref /REC2X
Reconfigure
To db ALANC/ACPROP
Xref /REC3X
Reconfigure
To db TAMH/THPROP
Xref /REC4X
Reconfigure
To db TAMH/PROP_ATEST
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
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
Copy all
Reconfigure
From db ALANC/ACPROP

Version 11.5
Reconfiguration
Copy all
Reconfigure
From db TAMH/THPROP
Copy all
Reconfigure
From db TAMH/PROP_ATEST
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.

Version 11.5
Reconfiguration
3.14.1 Standard Information Messages

The progress-monitoring messages, which indicate the stages reached during the
reconfiguration, are self-explanatory. They are:
:
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.
The format of this report is:
integer Elements were not defined in the DDL
integer Elements have been lost
integer Elements are no longer named
integer Attributes were incorrectly defined
integer Elements were not inserted
where integer is the relevant number.
3.14.2 General Format of Pass 2 Error Messages

In addition to the standard information messages described above, a range of error
messages may be generated during Pass 2. These messages have the general format:
CODE TYPE OLDREF NEWREF NAME
although some parts of this may be omitted.
For example:
EN EQUIP #10/21 =12/12 /NEWNAME
#EAE SHEE #88/842 =16/2417 /DR1/S5
*ENID SITE #15/23
The individual parts of the message are:
CODE: Identifies the nature of a message arising from the creation or naming of
an element. The codes used are detailed in the next section.
TYPE: The type of element, e.g. SITE, BRAN, SHEE etc.
OLDREF The reference number of the element in the source DB (starting with ‘#’).
NEWREF: The reference number of the corresponding element created in the
destination DB (starting with ‘=’). This will be blank if the element could
not be created.
NAME: 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).

Version 11.5
Reconfiguration
3.14.3 Codes Used to Identify Message Types

The coded prefix to each message comprises two parts. The first character is one of the
following:
• A space indicates information rather than an error
• An asterisk (*) indicates an error concerning the creation or naming of an element
• A hash (#) indicates an error concerned with an attribute
The remaining characters, which give more explicit meaning to the message, are
explained in the following subsections.
Information-only Messages (prefix: space)
There are two possible codes:
EC Element Created
EN Element Named
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 Elements Not In DDL
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 Element Not Inserted
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 Element Attribute Error
followed by one or more other messages giving more information about the error.
3.15 Database Transfers between Computers
Note: The hardware platforms currently supported allow binary compatibility of

databases, and so the information in this section will not usually be needed.
RECONFIGURER can be used for the transfer of PDMS DBs between different
computers, which may be of different types. Because reconfiguration is a two-pass
operation, the data can be copied from one computer and read back into a different one.

Version 11.5
Reconfiguration
The transfer operation is essentially an extension of the procedure for copying data
between projects, described in Section 3.12. RECONFIGURER makes provision for
translating the coding of the intermediate files to ensure compatibility between the
language requirements of different computers.
An alternative method of transferring data between different computers is to use the
OUTPUT command in Design, Draft, Paragon or Lexicon. For details of other data
transfer methods, see the VANTAGE PDMS DESIGN Reference Manual Part 1
(OUTPUT command).
3.16 Binary and Character Files
Data can be stored in two formats:

• Binary files are in a compact machine-readable form, but are generally specific to
a particular type of computer.
• Character files (which are usually in ASCII code) generally have to be much
larger to hold the same amount of information, but are human-readable. Character
files can be transferred relatively easily between different types of computers.
PDMS DBs are stored as binary files so that large amounts of data can be held
efficiently. RECONFIGURER provides a means to convert PDMS DBs from binary files
into character files and vice versa.
3.17 The 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:
FROM DB MASTER/DESI
TO FORM /F1 /F2
RCFCOPY ALL
RECONFIG
On destination machine:
FROM FORM /F1 /F2
TO DB MASTER/DESI
RECONFIG

Version 11.5
Reconfiguration
3.18 Reconfiguring a Global Project
We recommend that you use the SAMEREF option when reconfiguring a Global project.
We also recommend that there are no users in the database at the primary location
when reconfiguring back to the SAMEREF database.
Databases can only be reconfigured at their primary locations.
Note that when a project database is reconfigured, the database sessions will effectively
be lost. Thus the ability for Global to send only session changes is lost as well. When the
next update occurs between locations, the entire database will be sent via the Global
daemon. This can take some time if the database is large.
3.19 Reconfiguring Extracts
3.19.1 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 RECONFIG SAMEREF FULLThe SAMEREF Option

The SAMEREF option is always used for extracts. You need not to enter the SAMEREF
option; it is assumed.
This means that you can not reconfigure to DBs of a different DB number.
3.19.3 The SESSIONS Option

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

Version 11.5
Reconfiguration
3.19.4 Reconfiguring a Single Extract

The procedure for reconfiguring a single leaf extract is as follows:
1. Reconfigure from the DB to a file.
2. REVERT the extract to Session 1.
3. MERGE CHANGES to remove the intermediate session.
4. Reconfigure from the file to a DB.
An alternative strategy would be to replace Steps 2 and 3 by a DB deletion and a DB
creation.
The procedure is similar for single extracts that own other extracts. The only difference
is:
• The MERGE CHANGES command will leave sessions referred to by child extracts.
Thus, the resultant file will be larger than it would have been had there been no
extract children.
• The alternative approach of deleting and recreating the extract is not possible
unless all child extracts are also deleted and recreated.
• The Master DB should be reverted to Session 2 rather than Session 1.
3.19.5 Reconfiguring a Family of Extracts

When reconfiguring a whole extract family, the following considerations apply:
• The REVERT/MERGE operation must be done bottom-up, to minimise the number
of sessions kept.
• Reconfiguring from databases to files must be done top-down.
• Reconfiguring back from files to databases must also be done top-down, and you
must complete the reconfiguration for the whole extract. For example, if you
reconfigure all three database levels of a three level extract to files but only
reconfigure the top two file levels back to databases, the third database will be
corrupted due to the reconfiguration of the other two. For further details, see
section 3.19.7 below.
• Before reconfiguring out from a file, refresh the extract.
• 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:

Version 11.5
Reconfiguration
1. Refresh TEAMA/EXTRACT.
2. Reconfigure TEAMA/MASTER to file /A, /B.
3. Reconfigure TEAMA/EXTRACT to file /C, /D.
4. REVERT TEAMA/EXTRACT to Session 1.
5. MERGE CHANGES on TEAMA/EXTRACT.
6. REVERT TEAMA/MASTER to Session 2.
7. MERGE CHANGES on TEAMA/MASTER.
8. Reconfigure from file /A, /B to TEAMA/MASTER.
9. Refresh TEAMA/EXTRACT (to pick up changes made in Step 8).
10.Reconfigure from file /C, /D to TEAMA/EXTRACT.
3.19.6 The RCFUPDATE command

When the RCFUPDATE command is used on an extract, all affected attributes will be
updated regardless of whether or not the element has been claimed to the extract. This
means that, if many extracts of the same extract family are updated, the same changes
will be made to each of the extracts.
3.19.7 Example of Reconfiguring a Three Level Extract

Consider this three-level extract:
MASTER
EXT
EXTBOT
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 that the REFRESH, REVERT and MERGE CHANGES commands have not been
shown below.)

Version 11.5
Reconfiguration
FROM DB CTBATEST/MASTER
TO FILE /MASTERA /MASTERB
RCFCOPY ALL
RECONFIG SESSIONS
FROM DB CTBATEST/EXT
TO FILE /EXTA /EXTB
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):
FROM DB CTBATEST/MASTER
TO FILE /MASTERA /MASTERB
RCFCOPY ALL
RECONFIG SESSIONS
2. At location B (primary location for EXT):
FROM DB CTBATEST/EXT
TO FILE /EXTA /EXTB
RCFCOPY ALL
RECONFIG SESSIONS
3. At location C (primary location for EXTBOT):
FROM DB CTBATEST/EXTBOT
TO FILE /EXTBOTA /EXTBOTB
RCFCOPY ALL
RECONFIG SESSIONS
Steps 1 to 3, reconfiguring from databases to files, can be done in parallel.

Version 11.5
Reconfiguration
4. At location A (primary location for MASTER):

FROM FILE /MASTERA /MASTERB
TO DB CTBATEST/MASTER
RECONFIG
The user must now propagate the whole database to locations (B) and (C).
5. At location B (primary location for EXT)
FROM FILE /EXTA /EXTB
TO DB CTBATEST/EXT
RECONFIG
The user must now propagate the whole database to locations (C) and (A).
6. At location C (primary location for EXTBOT)
FROM FILE /EXTBOTA /EXTBOTB
TO DB CTBATEST/EXTBOT
RECONFIG
The whole database will be propagated to locations (A) and (B) automatically.
Steps 4 to 6, reconfiguring from files to databases, should be done consecutively.
3.19.8 Reconfiguring the Transaction Database in a Global Project

The Global Daemon stores most of the commands that it is asked to perform at a
location in a transaction database. Each location has its own transaction database.
For details, see Chapter 5, The Transaction Database.
If a transaction database becomes corrupt, it may be necessary to reconfigure it. For
information about this, see Running Global Projects with VANTAGE PDMS.
Note: The daemon for a location must be stopped before reconfiguring its transaction
database.

Version 11.5
4 The System and Global Databases
This chapter describes the ADMIN elements and their attributes, which are stored in
the System database (and, for a Global project, the Global database).
You can navigate to the elements in the System and Global databases, and query their
members and attributes in the normal way.
4.1 Standard Projects: the System Database
Figure 4-1 shows the structure of the System database in a standard (that is, non-
global) project.
A list of the elements and their attributes follows. For the attributes, the default value
(which is some cases, for example, the Owner of the Team World, is the only allowable
value) is shown, and there may also be a short explanation or additional information.
Some elements can exist in more than one place in the database hierarchy, for example,
DB Lists are owned by Teams and DB Sets. In this case the element is only described
once.
Session information is stored separately in the COMMs database; and the MISC
database stores inter-db macros and messages. The communications world element in
the COMMs database contains the project lock. This may be set or cleared using LOCK
and UNLOCK syntax.

Version 11.5
The System and Global Databases
/*
WORLD
World
/*S /*T /*U /*M /*DS /*RO /*SC /*ST /*ACR

STAT TMWL USWL MDBW DBSTWL ROWL SCOW STWLD ACRW
Status World Team World User World MDB World DB Set Role Scope Stamp ACR
World World World World World
RFWL
Module FTWL TEAM MDB DBSET ROLE SCOPE STAMP ACR ACRST
Font USER Scopes Stamps ACRs ACR
World Teams Users MDBs DB Sets Roles
World Groups
FNTF DBLI USLI TMLI EXTLI STLST ACRL

RUNF Font Stamp List ACR Lists
DB User Team Extract DB DBSTL DBL PEROP
Modules Files Lists Lists Lists Lists DBs DB List Perops
Runfile information: you can
only modify these elements DB
using the MODULE and EDIT
commands DBs DB
DBs
Figure 4-1 The System Database

The names of the top-level elements (for example, /*S,) are shown, followed by the element type and a short explanation.

Version 11.5
The Project Status World (STAT)

Attributes
Name /*S
Lock false
Owner /*
Prjnumber unset Project number 16 character text
Maxusers 999999 Integer =< 999999
Prjlck false Not used, see Comms DB
Prjdesc unset Project description 120 character text
Infa unset Project name 120 character text
Infb unset Project message 120 character text
Charset 0 Multibyte character set
Locrf nulref in a non-global project
The Runfile or Module World (RFWL)

Attributes
Name /name
Lock false
Owner /*S
The Runfile or Module Element (RUNF)
RUNF elements own runfile information: you can only modify these
elements using the MODULE and EDIT commands
Attributes
Name /name
Lock false
Owner /*RFWL
Smno Module number, for example: 1 for ADMIN
Security For example: Free for DESIGN
The Font World (FTWL)

Attributes
Name /name
Lock false
Owner /*S
Fontdirectory /%PDMSEXE%/
The Font File Element (FNTF)
Attributes
Name /name
Lock false
Owner /name

Command Reference Manua
Version 11.5
Irno US
Stno LINE
Fnma unset
Fnmb unset
Faangle 17
The Team World (TMWL) (not used in Global projects)

Attributes
Name /*T
Lock false
Owner /*
The Team Element (TEAM)
Attributes
Name /name
Lock false
Owner /*T
Description unset 120 character text
The Database List Element (DBLI)
Attributes
Name /name
Lock false
Owner /name
The Database Element (DB)
Attributes
Name /name
Lock false
Owner /name
Dbno n
Stype DESI Database type
Fino n File number
Area 0 Area number
Daccess Update Access type
Claimdb Implicit or Explicit for Multiwrite DBs, or unset
Projid unset 3 character text
Fcpyref Nulref
Bcpyref Nulref
Extractno n
Extract owner/name
Variant false
Controlled false

Version 11.5
The User List Element (USLI)

Attributes
Name /name
Lock false
Owner /name
The User World (USWL)
Attributes
Name /*U
Lock false
Owner /*
The User Element (USER)
Attributes
Name /name
Lock false
Owner /*U
Password /name
Security General
Acrli unset List of ACRs and ACRGRPs
The Team List Element (TMLI)
Attributes
Name /name
Lock false
Owner /name
The Extract List Element (EXTLI)
Attributes
Name /name
Lock false
Owner /name
The MDB World (MDBW)
Attributes
Name /*M
Lock false
Owner /*

Version 11.5
The MDB Element (MDB)

Attributes
Name /name
Lock false
Owner /*M
CurdbsList of current DBs
The DB Set World (DBSTWL)

Attributes
Name /*DS
Lock false
Owner /*
The DB Set Element (DBSET)
Attributes
Name /name
Lock false
Owner /*DS
The Database Set List Element (DBSTL)
Attributes
Name /name
Lock false
Owner /name
DBSTF Reference to a DBSET
The Database List Element (DBL)
Attributes
Name /name
Lock false
Owner /name
The Role World (ROWL) (Not used in Global projects)
Attributes
Name /*RO
Lock false
Owner /*
LACR false Sets Data Access Control on or off (Standard projects only)

Version 11.5
The Role Element (ROLE)

Attributes
Name /name
Lock false
Owner /*T
The Perop Element (PEROP)
Attributes
Name /name
Lock false
Owner /name
Affirm true
Opcreate ignore
Opmodify ignore
Opdelete ignore
Opclaim ignore
Opissue ignore
Opdrop ignore
Eclass unset Element Class
Aclass unset Attribute Class
Condition unset
Acrmessage unset
Note on setting the ECLASS attribute:
The syntax is:
.-----------<-------------.
/ |
*-----<----. |
/ | |
>--- ECLASS ---*--- noun ---+--- HIERarchy --+
| | |
`------------+----------------+--->
For example:
ECLASS BRANCH HIERARCHY EQUI HIERARCHY STRU
will include Branch and Equi members, but only STRUs themselves.
The Scope World (SCOW)
Attributes
Name /*SC
Lock false
Owner /*

Version 11.5
The Scope Element (SCOPE)

Attributes
Name /name
Lock false
Owner /*SC
Scosel unset Scope selection PML expression
The Stamp World (STWLD) (Not used in Global projects)
Attributes
Name /*ST
Lock false
Owner /*
The Stamp Element (STAMP)
Attributes
Name /name
Lock false
Owner /*ST
Desc unset
Func unset
Purp unset
Setdat unset
The Stamp List Element (STLST)
Attributes
Name /name
Lock false
Owner /name
Stlsf Nulref DB reference
Stsess 0 Session number for DB
The ACR World (ACRW)
Attributes
Name /*ACR
Lock false
Owner /*

Version 11.5
The ACR Element (ACR)

Attributes
Name /name
Lock false
Owner /*ACR
RolerefNulref Role name
Scoperef Nulref Scope name
The ACR Group Element (ACRST)
Attributes
Name /name
Lock false
Owner /*ACR
The ACR List Element (ACRL)
Attributes
Name /name
Lock false
Owner /name
Acrf list of references of ACRs in the ACR Group

Version 11.5
4.2 Global Projects
When you use the MAKE GLOBAL command to make a standard project into a global
project, the Standard System database is split into two new database files; the Global
database and the (local) System database.
A modified sysvir.dat virgin database is used to upgrade the System database file
xxxsys, where xxx is the 3-character project code. The communications world element
LCOMW is added. The glbvir.dat database template file is used to create the Global
database file xxxglb.
The existence of the xxxglb database file shows that the project is global.
The following elements are added:
• The communications world element LCOMW
• The Global Locations world element GLOCW, which will own GRPLI elements
which in turn own GRP elements
• The Global Team World element GTMWL
• The Global Stamp World element GSTWLD. If stamps exist in the System
database, they are all copied to the Global Stamp World element and deleted from
the System database.
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 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.

Version 11.5
/*
WORLD
World
/*S /*U /*M /*DS /*RO /*SC /*ACR /*T /*LC

STAT USWL MDBW DBSTWL ROWL SCOW ACRW TMWL LCOMW
Status World User World MDB World DB Set Role Scope ACR Team Comms
World World World World World World
(empty) (empty)
RFWL FTWL USER MDB DBSET SCOPE ACR ACRST

Modules Fonts Users MDBs DB Sets Scopes ACRs ACR Sets LCTIML LCOMC LCOML
World World Event Daemon Comms
Timer config Links
Li
RUNF FNTF TMLI EXTLI ACRL
Modules Font Team Extract DB DBSTL DBL ACR Lists LCTIMD LCOMD
Families Lists Lists DBs DB List Timings Scheduled
Runfile information: you can Updates
only modify these elements
using the MODULE and EDIT DB
commands DBs
Figure 4-2 The Local System Database in a Global Project

The names of the top-level elements (for example, /*S,) are shown, followed by the element type (for example, STAT) and a short
description, (for example, Status World)

Version 11.5
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.2.1 Structure of the Local System Database
Figure 4-2 shows the structure of the local System Database in a Global project.
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.
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.
The 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.

Version 11.5
The 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 /name
Lock false
Owner /*LC
Logfn /filenam Log file name
Logms false
Loglv 0 Diagnostic level
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 /name
Type LCOML
Lock false
Owner /*LC
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 /name
Lock false
Owner /name
Locrf /name Name of Location which has comms link
with current Location
Timer frequency of update events 120 character text:
(See below)
Times 0 Time window start
Timee 2400 Time window end
Timei 30 Interval in seconds between
communication attempts
Timeo 10 Number of re-tries
Execb unset 120 character text: name of
script to be run before
updates are transferred (optional)

Version 11.5
Execa unset 120 character text: name of script to be run after updates
are transferred (optional)
The Timer values are:
Minutes past the hour 0 - 59
Hours 0 - 23
Days 1 - 31
Months 1 - 12
Days of the week 0 (Sunday) - 6
For example:
Timer '0,30 * * * *' specifies every half hour, every day.
Timer '12 10,12,14,16,18 * * 1,5 '
specifies 12 minutes past the hours given,
Monday to Friday.
The attributes TIMES and TIMEE are not implemented at this release.
Files such as Isodraft files, external plot files and Design manager files are not
propagated automatically by the global daemon. However, there is a mechanism in 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 Management 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.
Attributes:
Levenl 5 Time interval for event loop (secs)
Lmerti Frequency of Automerges. 120 character text:
(settings as for Timer above)
Lmersu 3 Time in days after which successful commands should be deleted.
The value –1 means no deletion.

Version 11.5
Lmerfa 3 Time in days after which failed commands should be deleted. The
value –1 means no deletion.
Lmerdl false 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.
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 /name
Locrf /name Reference to Location communicating
with current Location
Lendti 604800 Command timeout period, in seconds
(default is 7 days in seconds)
Lmaxtr 100 Maximum number of retries to send command
Ltimei 120 Time interval between retries, in seconds
4.2.2 Structure of the Global Database

The Global System database contains Teams, Databases, Roles, Locations and Stamps.
Figure 4-3 shows the structure of the Global System database.

Version 11.5
WORLD
World
/*GS /*GL /*GRO /*GT /*GST

GSTAT GLOCWL GROLW GTMWL GSTWLD
Global Status Location World Global Global Global
World Role World Team World Stamp
World
ROLE TEAM STAMP

Roles Teams Stamps
GRPLI LOCLI LNKLI
Group List Location Links List
List DBLI STLST
PEROP
Perops DB List Stamp
List
GRP LOC LNK
Groups Locations Links DB
DBs
DBLOC
Figure 4-3 Structure of the Global System Database.
GSTAT Element (GSTAT)

Only one /*GS element can exist in the database and it is inherited from the STAT
element in the Standard System Database.
Attributes
Name /*GS
Lock false
Owner /*
Prjnumber unset Project number:
17 character text
Maxusers 999999
Prjdesc unset Project description:
120 character text
Charset -370086
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:

Version 11.5
• It does not own a user list element USLI .

• The DB element does not own an MDB list element MDBL.
• The DB element owns a single DBLOC element DBLOC.
Attributes
Name /*GT
Lock false
Owner /*
TEAM Element
Attributes
Name /name
Lock false
Owner /*GT
Description unset
The Database List Element (DBLI)
Attributes
Name /name
Type DBLI
Lock false
Owner /name
DB Element
The existing DB element will inherit a new (single) list element DBLOC which will hold
four additional attributes (see DBLOC). These attributes are attached to a new element
to facilitate separate claiming of both this element and the owner DB element. This
scheme will reduce the contention between the PDMS ADMIN module and the Plant
Design Globaldaemon.
Attributes
Name /name
Type DB
Lock false
Owner /name
Stype DESI
Fino n File number
Area 0 Area number
Daccess Update
Claimdb Explicit or Implicit if Daccess is Multiwrite
Description unset
Proj unset (except for Foreign DBs, where it is set to the project code)
Fcpyref Nulref
Bcpyref Nulref
Extractno n

Version 11.5
Variant false
Controlled false
DBLOC Element
Attributes
Name /name
Type DBLOC
Lock false
Owner /name DB element
Locrf /name Name of Primary Location
Prvrf Name of previous
Primary Location (normally unset)
Propg true Propagation flag
Picfd false Picture file propagation flag
DEALDB Ref Array Indicates locations where db is being de-allocated
The Global Role World (GROLW)

The Global Role World Element stores the ROLE elements in a Global project.
Attributes
Name /*GRO
Lock false
Owner /*
LACR false Sets Data Access Control on or off
The Role Element (ROLE)
Attributes
Name /name
Lock false
Owner /*T
The Perop Element (PEROP)
Attributes
Name /name
Lock false
Owner /name
Opcreate ignore
Opmodify ignore
Opdelete ignore
Opclaim ignore
Opissue ignore
Opdrop ignore
Eclass unset Element Class
Aclass unset Attribute Class

Version 11.5
Condition unset
Acrmessage unset
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 will has the following attributes:
Attributes
Name /*GL
Lock false
Owner /*
Aduuid text Daemon version string
Hubrf /name Hub Location Reference
Prvrf Nulref Previous Hub Reference (normally unset)
NxtHb Nulref Next Hub location (normally unset)
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 /name
Lock false
Owner /*GL
GRP Element
The characteristics of each group are defined by a GRP element which has the following
attributes:
Attributes
Name /name
Lock false
Owner /name
Description 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.

Version 11.5
LOCLI Element
The LOCLI element contains a list of all Location elements LOC, including offline
Locations and those which belong to Groups.
Attributes
Name /name
Lock false
Owner /*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 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 /name
Lock false
Owner /name
Locid XXX 3-letter identifier
Rhost rhost name host name
Iconn 1 Connection type:
1 = on-line
0 = off-line
Linit false Initialisation flag
Grprf Nulref Group reference set if
Location is added to a Group
Locrf /name Parent Location
PRMRF Primary location of system Database. If unset,
(and PRVRF is unset) the Satellite will be
administered locally
PRVRF Nulref Old primary location (normally unset)
DEALAL false Indicates that ALL DBs are currently being
de-allocated from this location

Version 11.5
CURLOC True current Location (available everywhere)

ADMLOC Currently administered location
(available everywhere)
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.
DBALL Element
Attributes
Lock false
Owner /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 /name
Type LNKLI
Lock false
Owner /*GL
LNK Element
Not used at this release.
Attributes
Name /name
Descriptions unset 120 character text
LNKRX
LINKRY
LINKWV
GSTWLD Element
Any existing stamps in the standard System database are copied to the Global Stamp
World element and deleted from the System database.
Attributes
Name /*GST
Lock false
Owner /*

Version 11.5
STAMP Element
Attributes
Name /name
Lock false
Owner /*ST
Desc unset
Func unset
Purp unset
Setdat unset
STLST Element
Attributes
Name /name
Lock false
Owner /name
Stlsf Nulref DB reference
Stsess 0 Session number for DB

Version 11.5
5 The 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 Structure of the Transaction Database
The hierarchical structure of the transaction database is shown in Figure 5-1.

All the owner/child relations are one to many with the exception of TRMLST, TRFLST,
and TRSLST. There is only one of each below an operation (TROPER) or output
command (TROUCO) or an input command (TRINCO).
There is no distinction between commands received from other locations (foreign) or
from the local location as there are no fundamental differences between them. Whether
they are local or foreign is determined by their position in the hierarchy and their
owner’s names.
The structure is a hierarchy leading to input commands received by the daemon, and
the operations these have evaluated to.

Version 11.5
The Transaction Database
%TRMSG
%TRYEAR
%TRMONT
%TRDAY
%TRUSER
%TRLOC
%TRINCO
%TROPER %TROUCO
%TRSLST %TRFLST %TRMLST
%TRSUCC %TRFAIL
%TRSUCC %TRMESS %TRFAIL
Figure 5-1 Structure of the Transaction Database.

Version 11.5
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
NAMEText /*MS
TRSETL Logical Controls whether Local claim commands are stored
5.3 TRYEAR, TRMONT and TRDAY elements
These are organisational elements to allow the commands stored in the transaction
database to be grouped by the date on which they were received. Each of these elements
only has a single attribute NAME that is of the form:
• Name of %TRYEAR – year number. For example, /2001
• Name of %TRMONT –as for year, then slash and month. For example, /2001/MAY
• Name of %TRDAY – as for TRMONT, followed by slash then date. For example,
/2001/MAY/21
TRYEARs own TRMONTs, TRMONTs own TRDAYs and TRDAYs own TRUSERs.
5.4 TRUSER and TRLOC elements
These are further organisational elements under which commands are stored as issued
by a specific user (TRUSER) and from a particular location (TRLOC). They each only
have NAME attributes.
A given transaction database will have a structure containing the TRDAY element for
any date on which input commands were received. This will own a TRUSER element for
each of the PDMS users that have issued daemon commands on that day. These will
own a single TRLOC element with the name of the local location (e.g. CAM). There is
only one TRLOC because the PDMS user only sends commands to the local daemon.
The TRDAY may also own a TRUSER for the local and remote daemons
(LOCALDAEMON and REMOTEDAEMON). These will own TROUCO commands
received using RPC from other locations. These will own TRLOC elements for each
location from which an input command has been received. LOCALDAEMON will own a
TRLOC for the local location (e.g. CAM) since operations can send commands to the local
site.

Version 11.5
The final system TRUSER element is named …/TIMEDUPDATES with a single TRLOC
of the local site. This contains commands issued to process the regular timed updates.
TRDAY TRUSER TRLOC TRINCO
/2002/MAR/25 /2002/MAR/25/LOCALDAEMON ../CAM CLAIM…etc
/2002/MAR/25/REMOTEDAEMON ../OXF CLAIM…etc
../LON CLAIM…etc
../HOU CLAIM…etc
/2002/MAR/25/TIMEDUPDATES ../CAM UPDATE ALL…etc
/2002/MAR/25/SYSTEM ../CAM CLAIM…etc
/2002/MAR/25/FRED ../CAM CLAIM…etc
/2002/MAR/25/ROSE ../CAM CLAIM…etc
…etc …etc …etc
5.5 TRINCO element (Input Command)
The TRINCO element stores the information about an input command issued to the
daemon from a user, or another location’s daemon. The information includes the state of
processing of the command and is sufficient for the command to be restarted when a
daemon is restarted, and is sufficient to generate the operations and output commands
necessary to execute the command.
Note that local commands added from PDMS, that is those with TRLOCL True, do not
contain successes, failures or messages.
Attributes
NAME text Not automatically generated
TRCNUM int Command number
INCSTA int The state of processing of the TRINCO
COMUID ref 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.
TRMODU int Module number through with the USER has issued
this command, or GLOBALDAEMON module
TRLOCL log True if command stored directly by PDMS
independent of the Daemon
COMSTR text Command string USER entered that generate this
command, else null
ORILOC[3] text Original Location where user issued the command

Version 11.5
DESLOC3] text 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.
PRVLOC[3] text Previous Location which passed the command on to
this location (normally the same as the TRLOC
element)
AUXLOC[3] text auxiliary location. Often used as a location to send
auxiliary commands
SYSLOC[3] text Location of administrator when being remotely
administered, else NULL
DEPCOU int number of other TRINCOs on which this is
dependent (always zero)
DEPEND[*] ref References of TRINCOs on which it is dependant,
(always none)
DEPTYP[*] log Type of dependencies - on success or failure
DATECR date Date command received and recreated
DATEAK date Date sent acknowledgement for command
NACKN int Number of times acknowledgement sent
EXTIME[4] text Time to execute command (hence allows a delay) –
DATERD date Date command made ready (after EXTIME has been
reached)
DATECM date Date command completed
DATERP date Date reply sent with results of command
NREPLY int Number of times reply sent
MSTEXT text text info set on completion (normally only if failed to
generate operations)
TRPASS log true if command succeeded, false if failed. The
command fails if any of its operations fail, or if it fails
to generate operations
DATEND date Date all processing of command finished –
acknowledgement of command received, or command
cancelled.
NREPAK int Number of times reply acknowledgement received
USERST text user cancelling the command
TRDBRF ref of Database DB element
TRFINO int file number of DB element

Version 11.5
TREXTN int extract number of DB element

TRAREA int area number of DB element
TRSTYP int filetype of DB element
TRDBNO int dbnumber of DB element
TRDACC int access type of DB element
INARCO int argument count for intargs (args of the command)
(defaulted to zero.)
INTARG[*] int Command arguments (passed around as a
Conformant array)
TRCARG[*] text Command argument qualifiers space separated. E.g.
‘NAME=X/Y’
TRVISI log Visible or not
DESC[256] text User description
Values of INCSTA state attribute and order of change

RECEIVED The command has been received ready for processing.
DATECR is set.
ACKNOWLEDGED An acknowledgement has been sent off by this daemon.
DATEAK is set and NACKN incremented.
STALLED The command has failed to create its operations and state
will later return to ACKNOWLEDGED ready for retry, or
to TIMEDOUT.
READY The command has reached its execute time and is
independent. DATERD is set.
COMPLETE The command has been processed, and results obtained.
DATECM is set.
REPLIED The daemon has sent the results back to the originating
location. DATERP is set and NREPLY incremented.
PROCESSED An acknowledgement for the result received from
originating location. DATEND is set and NREPAK
incremented.
REDUNDANT The command will not be executed now due to dependency
rules. DATEND is set.
CANCELLED The command has been cancelled and finished with
TRPASS false. DATEND is set.
TIMEDOUT The command has timed out before creating its operations
and finished with TRPASS false. DATEND is set.

Version 11.5
5.6 TROUCO element (Output Command)
The TROUCO element the information about an output command to be issued by the
daemon to itself, or to the daemon at another location. The information includes the
state of processing of the command and is sufficient for the command to be resent when
a daemon is restarted.
Output commands are generated by an input command when operations are created.
They may be destined to be executed at this, or another site.
Attributes
NAME text Not automatically generated.
TRCNUM int Command number of command being sent.
OUTSTA int State of processing of the TROUCO.
COMREF ref Ref of the TRINCO of this command stored in the
receiving location transaction database. This is NULL
until an acknowledgement is received.
ORILOC[3] text Original Location where user issued the command.
DESLOC3] text 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.
PRVLOC[3] text Previous Location which passed the command on to
this location (normally the same as the TRLOC
element).
AUXLOC[3] text Auxiliary location. Often used as a location to send
auxiliary commands.
SYSLOC[3] text Location of administrator when being remotely
administered, else NULL.
NXTARL[3]- text Next Target location – this is needed to determine
which port to assign the output command to, and
which location to send the command.
DEPCOU int Number of other TROPERs and TROUCOs on which
this is dependent.
DEPEND[*] ref References of TROPERs and TROUCOs on which it is
dependant.
DEPTYP[*] log Type of dependencies - on success or failure.
PREOP ref Reference of previous operation which generated this
output command as one of its post operations. If no
previous operation this is NULL.
DATECR date Date command created by owning input command.

Version 11.5
DATERD date Date command is ready to send after dependencies

satisfied.
DATESN date Date command sent to destination location.
NRETRY int Number of attempts when command was sent.
MAXTRY int Number of attempts sending command before
command fails.
WAITIM int Number of seconds delay between attempts at sending.
ENDTIM date Date when command will fail if sending remains
stalled.
DATEAK date Date acknowledgement received from destination
location
NACKN int Number of times acknowledgement received.
DATERP date Date reply with results received from destination
location.
DATERK date Date reply acknowledgement sent to destination
location
NREPLY int Number of times reply received.
MSTEXT text Text info set on completion (normally only if failed to
generate operations).
TRPASS log True if command succeeded, false if failed. This is
determined from the result received.
POPCOD int Code for post operation creation function to be run. If
none then zero.
DATEND date Date all processing of command finished all post
operations generated, or command cancelled, or
command timed out.
NREPAK int Number of times reply acknowledgement received.
USERST text User cancelling the command.
TRDBRF ref Reference for Database DB element.
TRFINO int File number of DB element.
TREXTN int Extract number of DB element.
TRAREA int Area number of DB element.
TRSTYP int Filetype of DB element.
TRDBNO int Dbnumber of DB element.
TRDACC int Access type of DB element
INARCO int Argument count for intargs (args of the command,
defaulted to zero).

Version 11.5
INTARG[*] int Command arguments (passed around as a Conformant

array)
TRCARG[*] text Command argument qualifiers space separated. E.g.
‘NAME=X/Y’
TRVISI log Visible or not
DESC[256] text User description
Values of OUTSTA state attribute and order of change

WAIT The command is waiting until it is independent of any
other operation/command. DATECR is set.
READY The command is independent and ready to be sent.
DATERD is set.
STALLED The command could not be sent. State will later return to
ACKNOWLEDGED ready for retry, or to TIMEDOUT.
SENT The command has been sent and waits for an
acknowledgement. DATESN is set, NRETRY is
incremented.
ACKNOWLEDGED An acknowledgement has been received from the
destination location. DATEAK is set, NACKN is
incremented, CMREF is set.
REPLIED A reply with results have been received from the
destination location. DATERP is set, NREPLY is
incremented.
COMPLETE A reply acknowledgement has been returned to the
executing location. DATERK, TRPASS, MSTEXT are set.
NREPAK is incremented.
STALLED_POSTOP Post operations could not be created. State will later return
to COMPLETE ready for retry, or to TIMEDOUT.
PROCESSED Any required post operations have been generated using
the result of this command. DATEND is set.
CANCELLED The command has been cancelled by owning TRINCO by a
user. DATEND is set.
TIMEDOUT The command has had the number of sends exhausted, or
maximum time exceeded. DATEND is set.

Version 11.5
5.7 TROPER element (Operation)
The TROPER element stores the information about an operation to be executed by the
daemon. The information includes the state of processing of the operation and is
sufficient for the operation to execute when a daemon is restarted.
Operations are generated by an input command when operations and output commands
are created.
Attributes
NAME text Not automatically generated.
TRONUM int Operation number of operation to execute. Note this
is not a command number.
OPSTAT int State of processing of the TROPER:
DEPCOU int Number of other TROPERs and TROUCOs on which
this is dependent.
DEPEND[*] ref References of TROPERs and TROUCOs on which it
is dependant.
DEPTYP[*] log Type of dependencies - on success or failure.
PREOP ref Reference of previous operation which generated this
output command as one of its post operations. In
none then NULL.
DATECR date Date operation created by owning input command.
DATERD date Date operation is ready to execute after dependencies
satisfied.
DATERN date Date operation was started running (executing).
NRETRY int Number of attempts to start operation running
MAXTRY int Maximum number of retries allowed before failure.
WAITIM int Number of seconds delay between attempts at
executing.
ENDTIM date Date when operation will fail if execution remains
stalled.
DATESL date Date operation stalled during execution.
DATECM date Date execution completed.
MSTEXT text Text info set on completion.
TRPASS log True if operation succeeded, false if failed.
POPCOD int Code for post operation creation function to be run. If
none then zero.

Version 11.5
DATEND date Date all processing of operation finished, all post

operations generated, or command cancelled, or
command timed out.
USERST text User cancelling the TROUCO – may not be
implemented.
TRVISI log Visible or not.
DESC[256] text User description.
Values of OPSTAT state attribute and order of change
WAIT The operation is waiting until it is independent of any
other operation/command. DATECR is set.
READY The operation is independent and ready to execute.
DATERD is set.
STALLED The operation could not be executed. State will later return
to READY (ready for retry), or to TIMEDOUT. DATESL is
set.
RUNNING The command has started running. DATERN is set,
NRETRY is incremented.
COMPLETE A reply acknowledgement has been returned to the
executing location. DATECM, TRPASS, MSTEXT are set.
STALLED_POSTOP Post operations could not be created. State will later return
to COMPLETE ready for retry, or to TIMEDOUT.
PROCESSED Any required post operations have been generated using
the result of this command. DATEND is set.
CANCELLED The command has been cancelled by owning TRINCO by a
user. DATEND is set.
TIMEDOUT The command has had the number of sends exhausted, or
maximum time exceeded. DATEND is set.
5.8 TRMLST, TRSLST, and TRFLST elements
The TRMLST, TRSLST, and TRFLST elements are organisational elements (Message
Lists, Success Lists and Failure Lists respectively):
• Messages (TRMESS) are grouped under Message Lists (TRMLST).
• Successes (TRSUCC) are grouped under Success Lists (TRSLST) and TRMLST.
• Failures (TRFAIL) are grouped under Failure Lists (TRFLST) and TRMLST.

Version 11.5
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 TRMESS, TRSUCC, and TRFAIL elements
The TRMESS, TRSUCC, and TRFAIL elements are for Messages, Successes and
Failures respectively.
Operations and Output Commands are able to have any number of messages attached to
them. They will be generated by Local operation during their execution and be stored.
Remote operations will receive messages from their output commands that will:
• 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 claime
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

Version 11.5
TROUCO and transmitted to other site TROPER elements. They are only stored under
the final TRINCO generated from a USER command.
Attributes for elements %TRSUCC and %TRFAIL
DATEMS date Date success/failure raised.
MESNUM[2] int[2] 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.
MSTEXT text Any result text (not passed on).
MSTYPE int Data type indicates significance of MESQUA,
MSREF, MSDTXT.
MESQUA int Data qualifier.
MESREF ref Data refno corresponding to the error.
MSDTXT text Data text of the result/error.
MSLOC text Name of location that generated the success/failure
TRCNUM int Source command type number (if generated by a
TRINCO).
TRONUM int Source operation type number (if generated by a
TROPER).
Attributes for element %TRMESS

DATEMS Date Date success/failure raised.
MESNUM[2] int[2] Message/error number relating to MSTEXT or 0,0 if
none available.
MSTEXT Text Message text.
MSLOC text Name of location that generated the success/failure.
MSSENT log Unused.
TRCNUM int Source command type number (if generated by a
TRINCO).
TRONUM int Source operation type number (if generated by a
TROPER).

Version 11.5

Version 11.5
6 Command Summary
This chapter lists the ADMIN commands in functional groups. Details of the commands
are given in Chapter 7 in alphabetical order of command name.
6.1 Project Definition

ACCESS Changes the access rights of the specified user to PDMS
modules.
ACRADD Adds a named ACR to the current ACR Group.
ACRREM Removes a named ACR from the current ACR Group.
ADD Places a named DB at a specified position in the current MDB
list.
CHANGE Changes database access type, and the claim mode for
multiwrite databases. (In a Global project, also changes
primary location)
CDESC Changes the description of the specified user, team, database
or MDB.
CNAME Changes the name of the specified user, team, DB or MDB.
COPY Copies a DB, MDB, Team, User, Module or Stamp.
CREATE Creates a DB (including Extract DBs), MDB, Team, User or
Module.
CURRENT Moves a DB to a specified position in the current MDB list.
DADD Adds a Database or DB Set to the current DB Set.
DEFER Makes a DB non-current.
DELETE Removes the specified element from the project.
DREMOVE Removes a DB or DB Set from the current DB Set
EXCHANGE Replaces the current DB by a non-current DB.
EXCLUDE Removes a database which has been included from an
external project.
INCLUDE Includes databases from another project in the current MDB.
NEW Creates a DB Set, Role, Scope, Access Control Right (ACR) or
ACR group.
PROJECT Adds descriptive information to project definitions.

Version 11.5
Command Summary
REPLICATE Saves the structure or contents of a project in a named file.

REMOVE Removes a DB from an MDB.
SET Sets the current MDB, Team or DB Set.
TADD Adds Users to the current Team.
TREMOVE Removes Users from the current Team.
6.2 Project Administration

BACKTRACK Backtrack a database to a previous session.
EXPUNGE Removes users from the Project and releases claimed
elements in databases.
EXTRACT Control of database extracts
LOCK Locks the Project Database so that Users cannot enter.
MAXUSERS Maximum number of users for a project.
MERGE CHANGES Merges the changes made to a database over several
sessions.
MESSAGE Sends messages to other users.
MOVE Moves a DB to a different area.
NEW STAMP Creates a new stamp.
REVERT Backtrack a database to a previous session.
UNLOCK Unlocks a locked database.
6.3 Global Project Administration

ADMINISTER Creates or opens a system database to allow you to administer
a remote location.
ALLOCATE Allocates databases to a Location.
DEALLOCATE Removes databases from a Location.
DUPLICATENAMES Checks for elements with duplicate names in the Project.
GENERATE Generates the files required for a new Location.
HUBLOCATION Relocates Project Hub.
INITIALISE Initialises communications link at a Location
ISOLATION Isolates a Location so that no updates take place.
MAKE GLOBAL Makes a Standard Project into a Global Project.

Version 11.5
Command Summary
NEW Creates a DB Set, Role, Scope, Access Control Right (ACR) or

ACR group.
PING Checks that communications link to named location exists.
PREVOWNER Restores the Hub to its previous Location.
Restores a database to its previous Primary Location.
PURGE Removes old Database files and Picture files from an offline
Location.
RECOVER Recovers data when a databases has been corrupted.
REMOTE Allows the Hub or the Administering Location of a Satellite to
carry out certain tasks.
REMOTEMESSAGE Sends messages to users at other Locations.
RENEW Deletes a transaction database and creates a fresh version.
REORDER Reorders a members list.
SET Sets the current MDB, Team, or DB Set.
SYNCHRONISE Updates a database with changes from another Location.
SYSTEMLOCATION Changes the Administering Location of a Satellite.
TRANSFER Generates a directory containing copies of all database files,
ready for transfer to a Location.
UPDATE Updates current Location and an immediate neighbour.
6.4 Module Definition

EDIT Enables project module entries to be edited.
MODULE Creates an entry for a module in the System DB.
6.5 Font Definition

FONTDIRECTORY Sets the font directory name.
FONTFAMILY Defines a font family.
6.6 Querying
LIST Lists Project Information
QUERY Queries information about ADMIN elements.
STATUSSESSION Gives information about the current state of the Project.
SYSTAT Gives information about users accessing the project.

Version 11.5
Command Summary
6.7 General PDMS Commands

ALPHA Sends command input and output to a file.
FINISH Leaves PDMS, saving work.
GETWORK Refresh view of System database.
SAVEWORK Updates the Project Database.
TERM Equivalent to ALPHA FILE END.
6.8 Data Integrity Checking

Within PDMS:
CHECK Starts the integrity checking.
CHECKOPTION Control what is to be checked, and the amount of information
output.
Stand-alone:
CHECK Starts the integrity checking.
ERRORFILE Specifies the name of the file containing the error and warning
messages when DICE is used in stand-alone mode.
EXTERNAL Checks that all external references point to DBs of appropriate
types.
MAXERRORS Maximum number of errors found before data integrity
checking is abandoned.
MAXWARNINGS Maximum number of warnings found before data integrity
checking is abandoned
MODE Specifies what happens when DICE finds an error.
STATISTICS Produces a summary of information about the database being
checked.
STOP Exits from DICE in stand-alone mode. (Equivalent to FINISH)
6.9 Reconfiguration
BRIEF Brief output to pass 2 reconfiguration.
DUMP Writes a reference number index to the given file.
ERRORS Sets an upper limit on the number of errors that are acceptable
during Pass 2 of a reconfiguration.
FILE Sets the output destination for reconfiguration messages (see
Chapter 3).

Version 11.5
Command Summary
FROM Specifies the source database for reconfiguration.

FULL Gives full output from pass 2 reconfiguration.
LOAD Loads the reference number index from the given file.
RCFCOPY Defines the part of the database to be copied from the source
DB to the destination DB.
RCFUPDATE Updates reference pointers into reconfigured database.
RCFUPGRADE Consult AVEVA Solutions Support.
RECONFIGURE Starts reconfiguration.
REINIT Re-initialises the reference number index.
RESETXREFS Consult AVEVA Solutions Support.
TO Specifies the destination database for a reconfiguration.
UPGRADE Produces macros to upgrade a project to a new version of
PDMS.
VB Gives very brief output for pass 2 reconfiguration.
XREF Consult AVEVA Solutions Support.

Version 11.5
Command Summary

Version 11.5
7 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 Conventions Used in the Syntax Graphs
The syntax graph conventions are as follows:

• Commands are shown in a combination of uppercase and lowercase letters, where
the capital letters indicate the minimum abbreviation. (Note: This convention
does not mean that the second part of the command must be typed in lowercase
letters; commands may be entered in any combination of uppercase and lowercase
letters.)
• For example, the command
CReate
can be input in any of the following forms:
CR
CRE
CREA
CREAT
CREATE
Commands shown in all uppercase letters cannot be abbreviated.
• Command arguments are shown in lowercase letters. These are just descriptions
of what you need to enter. For example:
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.
• 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:

Version 11.5
Command Details
>----+--- 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.

Version 11.5
Command Details
7.2 Notes on Syntax Graphs
<loc>
When a Location needs to be specified, it is shown as <loc> in the sysntax graphs. It can
be:
• A three-letter Word. For example: CAM, the LOCID of a LOC element, where the
LOCID is 3 capital letters.
• 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>
>--- time --- day --- month --- year
time is in the format hh:mm where hhx is the hour and mm the minutes. If not given
then the default of 23:59 is taken. There must not be any spaces around the colon.
day will be an integer. If not specified, the current day is taken. The day must be given
if no time was specified.
month can be entered as a word, or as a number separated by a slash. If not given the
current month is assumed. If used, the slash must be surrounded by spaces.
year will default to the current year. It may be entered as two or four figures.
Examples:
12:00 21 January 2002
9:30 11 / 1 / 02
10:30
21 / 1 / 2002
21 January

Version 11.5
Command Details
7.3 Detailed Descriptions of Commands
The detailed descriptions appear on the following pages in alphabetical order of

command name. Each description starts on a new page. The command name and
relevant functional group are at the top of the first page of the description, and the
command name is repeated on each continuation page.
When a command is associated with the Global Project Administration functional group,
the command is specific to Global projects. Commands associated with other functional
groups may be used for Standard and Global projects, and any particular aspect of a
command that concerns Global projects is highlighted by the appearance of 'Global' in
larger typeface.

Version 11.5
Command Details
ACCESS (Project definition)
Function: Changes the access rights of the specified user to PDMS modules.
Examples:
ACCESS ADMINUSER FREE DRAFTUSER GEN
Give user ADMINUSER FREE access, user DRAFTUSER GENERAL
access
Command Syntax:
.-------------<-------------.
/ |
>--- ACcess --*-- userid ---*--- FRee ------|
| |
`--- GEneral ---+--->
Related Commands: CREATE

Version 11.5
Command Details
ACRADD (Project definition)
Function: Adds an ACR to an ACR Group.
Description: The ACR and the ACR Group must already exist, and the ACR
Group must be the current element.
You can then give a list of ACR names to be added to the Group.
Note that ACR Groups cannot contain other ACR Groups.
Examples:
ACRADD /ACR1 /ACR22 /ACR24
Adds the ACRs /ACR1, /ACR22 and /ACR24 to the current ACR Group.
Command Syntax:
.----<-------.
/ |
>-- ACRADD --*--- acrname ---'
|
`--------------------->

Version 11.5
Command Details
ACRREM (Project definition)
Function: Removes an ACR from an ACR Group.
Description: The ACR Group must be the current element. You can then give a
list of ACR names to be removed from the Group.
Examples:
ACRREM /ACR1 /ACR22 /ACR24
Removes the ACRs /ACR1, /ACR22 and /ACR24 from the current ACR
Group.
Command Syntax:
.----<-------.
/ |
>-- ACRREM --*--- acrname ---'
|
`--------------------->

Version 11.5
Command Details
ADD (Project definition)
Function: Places a named DB at a specified position in the current MDB

list.
Description: The list position must be in the range 1 through 300. If no list
position is specified, the specified DB is added as a deferred
database (equivalent to DEFER).
Examples:
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, EXCHANGE

Version 11.5
Command Details
ADMINISTER (Global Project Administration - Remote Administration)
Function: Creates or opens a system database to allow you to administer a

remote location.
Description: Before you can use this command:

• The Location must have been created using the NEW LOC
command, and its Location identifier must have been set.
For example:
Locid 'AAA'
• The system database of the new Location must be made
Primary at the administering Location using the
SYSTEMLOCATION command. For example:
SYSTEMLOC /AAA PRIMARY AT /BBB
where /AAA is the identifier of the new Location, and /BBB is the
identifier of the Administering Location, that is, the location
where the System database for the Location will be Primary.
The NEWSYSTEM option is only available at the Hub. It creates a
system database for a new location in the transfer area. (This is
similar to the GENERATE LOCATION command.)
The system database created is a copy of the Hub system
database without MDBs and with only a SYSTEM user. The
Administrator at the Hub can then create Users and MDBs (as
well as Teams and Databases) for the Location before it is set up.
The SYSTEM option is available at the Administering Location,
that is, the location where the System database for the Location is
Primary. This may be the Hub or another Satellite. This
command will close the local system database and open the
appropriate satellite system database. The database will be
opened with Write access unless the READONLY keyword is used.

Version 11.5
Command Details
ADMINISTER (continued)
After the SYSTEM or NEWSYSTEM commands have been given, you

will be able to carry out administration tasks for the remote
location. To return to administering your own (current) Location,
give the command ADMINISTER LOCAL. To return to administering
the last system database which was open, give the command
ADMINISTER SAME.
Any location may issue an ADMINISTER command for another other
location’s system database. If the system database is not Primary,
then the system database will be opened READONLY.
Once you have selected a remote system database, you can give
most ADMIN commands, which will operate on the remote
Location. In particular, the following commands can be used for
housekeeping tasks on the remote System Database:
EXPUNGE SYSTEM
MERGE CHANGES SYSTEM
CHECK SYSTEM
RECONFIGURE SYSTEM
The Hub will not be allowed to REPLICATE the project when it is
administering a remote location, since the wrong system database
will be replicated. However REPLICATE SYSTEM commands (which
generate macros to replicate the project structure) will still be
valid.
The administered Location will be 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:
EXPUNGE
BACKTRACK
MERGE CHANGES
REVERT
CHECK
Reconfiguration will also be possible provided that suitable
databases are primary at the location.

Version 11.5
Command Details
ADMINISTER (continued)
Examples:
ADMINISTER NEWSYSTEM /Cambridge
ADMINISTER NEWSYSTEM 'CAM'
Allows the Hub Administrator to create data (Users, MDBs etc) for a
Location in the transfer directory.
ADMINISTER SYSTEM /Cambridge
ADMINISTER SYSTEM 'CAM'
Allows any System Administrator to read the System Database for
Cambridge. Only the Administrator at the Location where the
Cambridge System Database is Primary will have write access to it.
ADMINISTER SYSTEM SAME
Allows a System Administrator who is administering other Locations
to open the last System database opened.
ADMINISTER SYSTEM LOCAL
Allows a System Administrator who is administering other Locations
to open the local System database.
ADMINISTER SYSTEM AT /Cambridge
ADMINISTER SYSTEM LOCAL READONLY
This is equivalent to entering the ADMIN module as ADMIN
READONLY.
Command Syntax:
>-- ADMINISTER --+--- NEWSYSTEM <loc> -----------------------------.

| |
`--- SYSTEM ------+-- AT <loc> ---. |
| | |
|--- SAME -------| |
| | |
`--- LOCAL ------+--- READONLY --|
| |
`---------------+--->
Querying: >--- Q CURLOC ---> Returns the true current location

>--- Q ADMLOC ---> Returns the currently administered
location

Version 11.5
Command Details
ALLOCATE (Global Project Administration - Hub only)
Function: Allocates databases and copies them to a Location.
Description: Each Location has a list of databases that are allocated to it. The
ALLOCATE command adds a database to this list. A named
database or all databases can be specified. The allocation can be
deferred until a given time. The databases must already exist at
the Hub.
The Hub sends its own copy of the database, or that of the
Location’s parent, to the Location. This is not necessarily the most
up-to-date copy. Note that the Database will also be allocated to
all ancestors of the Location, if it is not already allocated to them.
When a DRAFT Database is allocated, the picture files are not
automatically copied with it. They will arrive with the next
update.
By default, the allocated databases will be Secondary, but you can
specify that they will be Primary. If a database already exists at a
location, you can change its Primary/Secondary status using the
CHANGE command.
Several Databases can be allocated in the same operation using
the ALLOCATE command.
In order for an extract database to be used at a satellite, all
owning extracts must also have been allocated there.
Offline Locations
The ALLOCATE PRIMARY option cannot be used. Use
ALLOCATE followed by CHANGE PRIMARY. The date option is
not allowed.
Note that ALLOCATE should be followed by a TRANSFER
command to copy the database to the location. The CHANGE
PRIMARY command should not be issued until this has been
done.
Using macros to Allocate Databases
You will probably use a macro for long lists of databases
allocations, for example, when a project is first set up.
The allocation process may take some time if there is a slow link
between Hub and Satellite and/or if databases sizes are large.
Note that if a de-allocation is in progress, then the allocation will
stall until the de-allocation is complete before commencing.

Version 11.5
Command Details
ALLOCATE (continued)
Make sure that you do not try to allocate a database to the same
location twice. If the allocation appears to have failed, check the
transaction databases at both the Hub and the Satellite before
attempting to repeat the command.
To check that the allocation has been successful, GETWORK and
then navigate to the LOC element. Navigate to its DBALL
(allocation list) member, and query its members. Wait until 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:
ALLOCATE PIPE/PIPE PRIMARY AT CAM
Copies database PIPE/PIPE from the current Location to Location
CAM, making it Primary
ALLOCATE ALL AT LON AT 23:30
Copies all databases which exist at the current Location but do not
exist at Location LON, from the current Location to Location LON, at
2330 hrs. The Primary/Secondary status will not be changed.
ALLOCATE ALL AT OXF OVERRIDE PROPG
Copies all databases, including non-propagating databases, which exist
at the current Location but do not exist at Location OXF, from the
current Location to Location OXF. The Primary/Secondary status will
not be changed. Transaction databases will not actually be copied, but
empty database files will be created at secondary locations. This
command is useful when changing the Hub location, since it ensures
that the DB allocation lists of the old and new Hub locations match.

Version 11.5
Command Details
ALLOCATE (continued)
Command Syntax:
>-ALLOCate -+- teamid -.

| |
|----------+- dbname -+-------------.
| | |
| |- PRIMary ---|
| | |
| `- SECOndary -+-AT loc-+-AT <time>----.
| | |
| `--------------+->
|
`- ALL ----------------------------AT loc-+-AT <time>-------.
| |
`-OVERride PROPG -+->
Related Commands: DEALLOCATE, CHANGE dbname PRIMARY, HUBLOC,

TRANSFER
Querying: >--- Q DBALL ---> At a location, shows the list of

allocated DBs
>--- Q DBLC ---> At a DB, shows the list of locations
that have the DBs allocated

Version 11.5
Command Details
ALPHA (General PDMS Command)
Function: Sends the information output in the Command Input and Output
window to a file.
Examples:
ALPHA LOG /LOG OVERWRITE
Sends all information displayed in the Command Input and Output
window to a file named log.
ALPHA FILE /LOG
Sends reports to a file named log, for example, a DICE report.
ALPHA LOG END
Ends recording.
Command Syntax:
>-- ALPha ---*--- LOG ---+--- filename ---+--- OVERwrite -------------------|

| | | |
| | |--- APPend ----------------------|
| | | |
| | `-----------------+-- COMMands ---|
| | | |
| | |-- REQuests ---|
| | | |
| | `---------------|
| | |
| `--- END ------------------------------------------|
| |
`--- FILE ---+--- filename ---+--- OVERwrite ------------------|
| | |
| |--- APPend ---------------------|
| | |
| `--------------------------------|
| |
`--- END -----------------------------------------+-->
Related Commands: TERM

Version 11.5
Command Details
BACKTRACK (Project Administration)
Function: Allows you to backtrack a database to a previous session.
Description: Sessions are defined as the work done between SAVEWORK

commands. You can backtrack to the date or session number
required, or, if the required session has been stamped, you can
backtrack to the stamp. The current state of the database will be
lost.
In a Global Project, this command can only be used when the

databases are Primary at your administering Location.
In a Global project, use the REMOTE <loc> BACKTRACK

command to backtrack a constructor database that is Primary at
a remote Location, where <loc> is the Location identifier. See the
REMOTE command for examples.
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.
Note: For extracts, the REVERT command is used instead of
BACKTRACK.
Examples:
BACKTRACK HANGERS/PADD TO SESSION 4
Backtracks the HANGERS/PADD database to Session 4. The team id
(HANGERS) and TO can be omitted.
BACKTRACK HANGERS/PADD TO STAMP /stamp_007
Backtracks the HANGERS/PADD database to the session that has the
stamp stamp_007. The team id (HANGERS) and TO can be omitted.
BACKTRACK /HVAC 10:30 31 / 8 / 96
BACKTRACK /HVAC 10:30 31 AUGUST 1999
Backtracks the HVAC database to10.30 am on the 31 August 1999. If
the time is omitted, 11.59 p.m. is assumed. If the month is not given,
the current month is assumed. If the year is not given, the current year
is assumed. This example assumes that the team name has been
specified using the SET command.

Version 11.5
Command Details
BACKTRACK (continued)
BACKTRACK PIPE/PIPE-A AT OXF TO SESSION 4

In a Global project, backtracks the PIPE/PIPE-A database at Location
OXF to Session 4. The team id (PIPE) and TO can be omitted. (The
database PIPE/PIPE-A must be Primary at the Location OXF,) and
the System Database for OXF must be Primary at the current
Location. See the ADMINISTER SYSTEM command.
Command Syntax:
>- BACKTrack -+- teamid -.

| |
‘----------+- dbname TO <when> --->
Querying: Q SESSION
Related Commands: REVERT, MERGE CHANGES,

REMOTE BACKTRACK, REMOTE REVERT - Global only

Version 11.5
Command Details
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.
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

#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

the attribute given
#EAE SHEE #53/819 =22/2402 /DR1/S3

the attribute given
Command Syntax:
>--- Brief --->
Related Commands: FULL, VB, ERRORS

Version 11.5
Command Details
CANCELCOMMAND (Global Project Administration)
Function: Allows a daemon command being executed at the current location

to be cancelled.
Description: The command to be cancelled must be in the ACKNOWLEDGED,

READY, RECEIVED or STALLED state. See Section 5.5,
TRINCO element (Input Command) for information about the
different states. A READY command cannot be cancelled if it has
running operations.
Examples:
CANCELCommand TRINCO1 OF /2002/APR/23/USERA/LON
Command Syntax:
>--- CANCELCommand <gid> --->

where <gid> is a TRINCO in the transaction database for the Location.
Related Commands: REMOTE CANCEL

Version 11.5
Command Details
CDESC (Project definition)
Function: Changes the description of the specified User, Team, Database or

MDB.
Description: The CDESC command is used to set a description for elements

created without one, or to overwrite an existing description.
Note: This command can only be used with Users, Teams,
Databases and MDBs. For all Admin elements, the
description can be set or changed by navigating to the
element and setting the Description attribute directly.
Examples:
CDESC USER TEST/TEST ’This is a test user’
CDESC TEAM TEST ’This is the test team’
CDESC DB TEST/DESI ’The test design database’
CDESC MDB TEST ’This is the test MDB’
Command Syntax:
>--- CDesc ---+--- USer username/password ’text’ ---.

| |
|--- TEam name ’text’ ----------------|
| |
|--- MDB name ’text’ -----------------|
| |
‘--- DB dbname ’text’ ----------------+-->
Related Commands: CNAME, CHANGE

Version 11.5
Command Details
CHANGE (Project definition)
Function: Changes database access type (UPDATE or MULTIWRITE), and

the claim mode for multiwrite databases.
It also changes the file number and control mode, and brings
foreign DBs up to date.
In a Global Project, this command can only be given at the Hub.

It can also be used to change the Primary Location of a database.
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.
Notes: 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.

Version 11.5
Command Details
CHANGE (continued)
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.
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:
CHANGE TEST/TESTDESI ACCESS MULTIWRITE
Change access rights to named database to multiwrite.
CHANGE TEST/TESTDESI CLAIM IMPLICIT
Change claim mode for named DB to IMPLICIT. This option can only
be used for a MULTIWRITE database.
CHANGE TEST/TESTDESI ACCESS UPDATE
Change access rights to named DB to single write.
CHANGE TEST/TESTDESI CLAIM OFF
Change claim mode for named DB to OFF. This option can only be used
for a CONTROLLED database.
CHANGE TEST/TESTDESI CONTROL OFF
Change control setting for named DB to OFF. This option can only be
used for a CONTROLLED database.

Version 11.5
Command Details
CHANGE (continued)
CHANGE TEST/TESTDESI FINO 500

Change the Filenumber (FINO attribute) of the given database to the
given number. By default, the Filenumber will be set to 0, and the
filename of the database file will be derived from the database number.
Using the default is recommended, particularly if you are using
extracts. If you set the filenumber explicitly, the extract filename will
still be derived from the Database number (NUMDB attribute), and so
the consistency of filenames within an Extract family will be lost.
CHANGE TEST/TESTDESI FINO 0
Change the Filenumber (FINO attribute) of the given database to 0.
This command can be used to update database files to the new file
numbering convention introduced at PDMS 11.3, which will keep
Extract filenames consistent within an Extract family.
CHANGE FOREIGN PIPE/PIPECATA RESET
If PIPE/PIPECATA is a local database in project AAA, and a foreign
database in project BBB, and the access is changed (in AAA), you
should give this command in project BBB to update the project.
Notes on the following Change...Primary Commands
The new Primary Location will receive all outstanding updates of
the database from the current Primary Location.
Offline Locations: Note that 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:
CHANGE TEST/TESTDESI PRIMARY AT CAM
Change the primary location of the named DB to be CAM. The
database will automatically become secondary at the current Primary
location.
The following option is only available at the Hub of a Global Project:

CHANGE HVAC/HVAC PRIMARY AT CAM AT 2330
Change the Primary Location of the named DB to the Location CAM at
the specified time.

Version 11.5
Command Details
CHANGE (continued)
Command Syntax:
>- CHange -+- dbname -+--- ACCess ---+--- MULTIWrite ----.

| | | |
| | |--- CONTRolled ----|
| | | |
| | ‘--- UPDAte --------|
| | |
| |--- CLAIM ----+--- IMPLicit ------|
| | | |
| | |--- EXPLicit ------|
| | | |
| | ‘--- OFF -----------|
| | |
| |--- FINO -----+--- n -------------|
| | | |
| | ‘--- 0 -------------|
| | |
| ‘--- CONTROL --+--- ON ------------|
| | |
| ‘--- OFF -----------|
| |
`- FOREIGN dbname RESET ----------------------+--->
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.
The following option is only available at the Hub of a Global Project:
>--- CHange dbname --- PRIMary AT <loc> ---+-- AT <date> --.

| |
`---------------+--->
Querying: >--- Query DB dbname --->

>--- Q PRMLOC ---> At a DB, shows the primary location.
Related Commands: PREVOWNER, TRANSFER (Global only)

Version 11.5
Command Details
CHECK (Data Integrity Checking)
Function: Starts the integrity checking of the databases specified.
Description: Using the CHECK command from within a PDMS project, you can
check:
• The System, Miscellaneous and Comms databases
• One or more named databases
• All the databases in a project
For information about using DICE (the PDMS Data Integrity
Checker) as a stand-alone program, see Chapter 2, 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.
Examples:
CHECK DBS MASTER/DESI MASTER/CATA
Checks the integrity of a single named DB or a series of DBs within the
project. Up to ten DBs may be specified in each command.
CHECK SYSTEMDB
Checks the integrity of the project’s System DB. In a Global Project,
the current administered System DB is checked.
CHECK COMMDB
Checks the integrity of the project’s Comms DB.
CHECK MISCDB
Checks the integrity of the project’s Misc DB.
CHECK GLOBALDB
Checks the integrity of the project’s Global DB.

Version 11.5
Command Details
CHECK (continued)
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
CHECK FILES /TRA000/TRA003 /TRA000/TRA001
Checks the integrity of one or more DBs by specifying the names of the
files in which the DBs are held. Up to ten files may be specified in each
command. This version of the command is usually used in stand-alone
mode.
(A list of DBs in a project, together with the names of the
corresponding files in which they are stored, can be produced by using
the LIST FILES command.)
Note: If DICE is being used within PDMS and the CHECK FILES
option is used, then no external reference checking can be done
for that file and EXTERNAL NOCHECK will be assumed.
Command Syntax:
From a PDMS module:
.------<----.
/ |
>- CHEck -+- DBs --*-- dbname ---+-----------------------------------.
| |
|- SYStemdb -----------------------------------------------|
| |
|- GLOBaldb -----------------------------------------------|
| |
|- COMMdb -------------------------------------------------|
| |
|- MISCdb -------------------------------------------------|
| |
`- PROject ------------------------------------------------+-->

Version 11.5
Command Details
CHECK (continued)
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

Version 11.5
Command Details
CHECKOPTION (Data Integrity Checking)
Function: Sets the options for database integrity checking.
Description: The CHECKOPTION command is used to control the level of detail

output by by a CHECK command. You can specify whether or not
you want to check references to other (external) databases. You
can also check consistency of claimlists, and, if there are errors,
instruct PDMS to correct them where possible.
Use the CHECKOPTION command to set up the output you
require, and then use the CHECK command to perform the check.
Note: This command is only available within a PDMS project.
The corresponding top-level commands MODE,
STATISTICS, MAXERRORS and MAXWARNINGS are
available when running stand-alone DICE or REMOTE
CHECK.
Controlling the Amount of Information Output
There are two types of DB fault detected by DICE:
• An error is identified if the DB is corrupted internally.
• 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.

Version 11.5
Command Details
CHECKOPTION (continued)
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.

Version 11.5
Command Details
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: Element ref/ref is not in parent extract claim list
702: Element ref/ref is claimed to another user/extract
703: Element ref/ref needs claiming to child extract in
parent extract
704: 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:

Version 11.5
Command Details
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.)
Command Syntax:
>--- CHEck OPTion ---+- EXTernal --+- CHECK -+-----------------------.

| | | |
| | `- PREFerence -+- NONE -|
| | | |
| | `- mdb --|
| | |
| |-- NOCHeck ----------------------|
| | |
| `-- REject -----------------------|
| |
|- MOde -------+-- FUll ------------------------|
| | |
| `-- BRief -----------------------|
| |
|- STATistics -+-- FULL ------------------------|
| | |
| |-- ON --------------------------|
| | |
| `-- OFF -------------------------|
| |
|- MAXErrors n ---------------------------------|
| |
|- MAXWarnings n -------------------------------|
| |
|- CLAIM ------+-- ON --------------------------|
| | |
| `-- OFF -------------------------|
| |
`- PATCh ------+-- ON --------------------------|
| |
`-- OFF -------------------------+-->
Related Commands: CHECK

Version 11.5
Command Details
CNAME (Project definition)
Function: Changes the name of the Element.
Description: This command is the only way in which the System Administrator
can change a user’s password without deleting and recreating the
user. Note that users can change their own passwords using the
PASSWORD command in MONITOR.
The CNAME DB command must be used with great care. If both

quoted DBs already exist, and if the OVER option is used, ADMIN
will copy the second DB into the first DB, and will then delete the
second DB. If, in the same circumstances, the OVER option is not
used, ADMIN will generate an error message.
In a Global Project, you can only change the Name of a Team or

a Database at the Hub.
Examples:
CNAME USER JF RAB/ROB
Change username JF to username RAB, password ROB
CN DB /GBPADD /GBDRAFT
Change DB GBPADD to GBDRAFT if GBDRAFT does not exist.
CN DB /GBPADD /GBDRAFT OVER
Change DB GBPADD to GBDRAFT even if GBDRAFT exists.
In a Global project, if /GBDRAFT already exists, then it must not be

allocated to locations other than the Hub, since the CNAME will delete
this database.
CN MDB /DES1 /DESIGN
Change MDB name /DES1 to MDB name /DESIGN
CN TE GEORGEB GEORGEC
Change team name GEORGEB to GEORGEC.

Version 11.5
Command Details
CNAME (continued)
Command Syntax:
>-- CName --+-- USer --- username username ---+--- /password---.

| | |
| ‘----------------|
| |
|--- DB --- dbname dbname ---+--- OVER ------------|
| | |
| ‘---------------------|
| |
|--- MDB --- mdbname mdbname ----------------------|
| |
‘--- TEam -- teamname teamname --------------------+->
Related Commands: CHANGE, EXCLUDE, INCLUDE, MOVE, CDESC

Version 11.5
Command Details
COPY (Project definition)
Function: Creates a copy of a DB, MDB, Team, User, Module or Stamp.
Description: Any number of copies may be made. Copies of databases have the
same database number as the original. An MDB cannot contain
more than one database with the same database number.
To avoid the risk of database corruption, databases must always
be copied using this command in ADMIN and not by using
operating system utilities or commands.
Note that extract databases and databases which own extracts
cannot be copied. This also applies when copying from foreign
projects.
In a Global Project, you can only copy Teams and Databases at

the Hub.
Examples:
COPY DB ADMIN/CA1A TO ADMIN/CA1C TO AREA 051
Copies DB ADMIN/CA1A to area 051, renaming it ADMIN/CA1C
COPY TEAM TESTTEAM TO SUPPORT
Team SUPPORT will be the same as team TESTTEAM when queried.
COPY TEAM TESTTEAM TO SUPPORT EXCL USERS
Team SUPPORT will be the same as team TESTTEAM when queried,
but the team’s users will not be copied.
CO MDB /ADMIN TO /ADMINCOPY
MDB /ADMINCOPY will contain the same structure as /ADMIN.
CO USER ADMINA TO TESTA/GEN
A new user TESTA, password GEN will be created, belonging to the
same teams, and having the same access rights as, user ADMINA
COPY DB Z/Z FROM PROJ ABC US SYSTEM/XXXXXX TO A/A
DB Z/Z will be copied from project ABC, so that it can be accessed by
user SYSTEM, password XXXXXX, into the current project. It will be
given the name A/A.
COPY DB Z/Z TO A/A TO AREA 99 TO FINO 50
DB Z/Z will be copied to A/A, in area number 99 with filenumber 50.
The environment variable pointing to area 50 will need to be set.
COPY STAMP /stamp_005 TO /stamp_012
The stamp stamp_012 will be a copy of the stamp stamp_005. The list
of databases referenced will be identical.

Version 11.5
Command Details
COPY (continued)
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 -------------------------------+->
Related Commands: CREATE, INCLUDE

Version 11.5
Command Details
CREATE (Project definition)
Function: Creates USERs, TEAMs, Databases (including Extracts) and

MDBs.
Description: Update databases can be accessed by one writer and many

readers. All PDMS databases can be update.
Multiwrite databases can be accessed by many writers and many
readers. DESIGN, CATALOGUE, DRAFT and ISODRAFT
databases can be multiwrite.
Multiwrite databases can have their claim mode set to IMPLICIT,
in which case any element that 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
module.
In addition, both types of Database can be Controlled, which
means that access will be controlled by an external system.
You can create Extract databases from standard (Master)
multiwrite databases. Extract databases can be standard extracts
or working extracts, and in addition, both standard and working
extracts can be variant extracts. Examples of creating the
different types of extracts, and the full syntax, are given here. For
general information about using extracts in projects, see the
VANTAGE PDMS ADMIN User Guide; for information about
using extracts in Global projects, see Running Global Projects
with VANTAGE PDMS.
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.

Version 11.5
Command Details
CREATE (continued)
In a Global Project, you can only create Teams and Master

Databases at the Hub. Extracts can be created at any 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.
Examples:
Creating Teams, Users and MDBs

CR TEAM PIPING
Create Team PIPING
CREATE USER RAB/ROB
Create User RAB with password ROB, default access rights
CRE US HHJ/MICK FREE
Create User HHJ with password MICK, free access rights
CR MDB /STEEL
Create MDB /STEEL
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.
CREATE DB PIPING/PIPEDB DESI
Create Design database PIPING/PIPEDB
CREATE DB STEEL/STEELDB DESI ACC MULTIW CLAIM EXPL
Create multiwrite Design DB STEEL/STEELDB, with explicit claim
mode.
CREATE DB STEEL/STEELDB DESI ACCESS MULTIWRITE DBNO 901
Create multi-write Design DB STEEL/DESI, database number
(NUMBDB attribute) 901.
CREATE DB TEST/TESTDESI FINO 500
Create the database TEST/TESTDESI with the given Filenumber
(FINO attribute). By default, the Filenumber will be set to 0, and the
filename of the database file will be derived from the database number.

Version 11.5
Command Details
CREATE (continued)
Using the default is recommended, particularly if you are using

extracts. If you set the filenumber explicitly, the extract filename will
still be derived from the Database number (NUMDB attribute), and so
the consistency of filenames within an Extract family will be lost.
CREATE DB TEST/TESTDESI FINO 0
Create the database TEST/TESTDESI with the Filenumber (FINO
attribute) of the given database set to 0. This command can be used to
update database files to the new convention introduced at PDMS 11.3,
which will keep Extract filenames consistent within an Extract family.
CREATE DB PIPE/PIPEEB DESI IN AREA 501
Create Design DB PIPE/PIPEDB in area 501
Creating Standard Extracts

CREATE EXTRACT PIPING/PIPE-X1 FROM PIPE/PIPEDB
Create an extract PIPING/PIPE-X1 from database PIPING/PIPEDB
CREATE EXTRACT ADMIN/PIPE-X1 FROM PIPE/PIPEDB
Create an extract ADMIN/PIPE-X1 from database PIPING/PIPEDB.
Note the extract can be owned by a different Team from its owner.
CREATE EXTRACT PIPING/PIPE-X1 FROM PIPE/PIPEDB EXTNO 100
Create an extract PIPING/PIPE-X1 with extract number 100 from
database PIPING/PIPEDB.
Creating a Master database above an existing Master database

CREATE MASTER PIPING/PIPE-X1 ABOVE PIPE/PIPEDB
Create a new master database PIPING/PIPE-X1 above existing master
database PIPING/PIPEDB. This means that PIPE/PIPEDB is now a
child extract of the new master PIPING/PIPE-X1
Creating Working Extracts

Working extracts can only be created from a database that is primary at the
current location.
CREATE WORKING EXTRACT FROM DB PIPING/PIPEDB FOR USERA
Create a working extract from PIPING/PIPEDB for USERA
CR WORK EXTR FROM DB PIPING/PIPEDB FOR USERB EXTNO 21
Create a working extract from PIPING/PIPEDB for USERB with
extract number 21.
Creating Variant Extracts

CREATE VARIANT TEST/PIPE-V1 FROM PIPING/PIPEDB
Create Design database PIPING/PIPEDB

Version 11.5
Command Details
CREATE (continued)
Creating Extracts for a satellite

CREATE EXTRACT PIPING/PIPE-X1 FROM PIPE/PIPEDB AT LON
Create an extract PIPING/PIPE-X1 from database PIPING/PIPEDB
at satellite with LOCID ‘LON’
Creating Transaction databases (Global projects only)

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 are created as OVERWRITE databases.
Command Syntax:
Databases
>- CReate DB teamid/dbname -+- CATA -.

| |
|- COMP -|
| |
|- DESI -|
| |
|- ISOD -|
| |
|- PROP -|
| |
|- PADD -|
| |
‘- DICT -+- IN AREA n -.
| |
‘-------------+---> cont
cont >--- ACCess -+- UPDATE -----.

| |
+- CONTRolled -.
| |
`- MULTIWrite -+- CLAIM -+- EXPLicit -|
| |
`- IMPLicit -+-----------+-->
cont

Version 11.5
Command Details
CREATE (continued)
cont >---+-- EXTNO n -.

| |
`-----------+- DBNO n -.
| |
`----------+-- FINO n --.
| |
`-------------+-- DESC text --.
| |
`---------------+--->
userid and teamid are alphabetic character strings up to 32 characters long

and passwd is an alphabetic character string up to six
characters long.
name is a normal PDMS name consisting of a slash (/) followed
by up to 31 alphanumeric characters.
dbname is a 32-character name
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 --------------------> cont
>- CReate WORKing EXTRact FROM team/db FOR user ----------> cont
cont >---+- IN AREA n -.

| |
‘-------------+- CONTROL -.
| |
`-----------+- CLAIM -+- IMPLicit -.
| | |
| `- EXPLicit -|
| |
`----------------------+--> cont

Version 11.5
Command Details
CREATE (continued)
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 with VANTAGE PDMS 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.
Transaction Databases (Global projects only)
>- CReate DB TRANSACTION/name ------------cont >
cont >--+-- EXTNO n -.

| |
`-----------+- DBNO n -.
| |
`----------+-- FINO n --.
| |
`-------------+-- DESC text --.
| |
`---------------+--->
The ‘name’ must be the LOCID of a valid Location.

Version 11.5
Command Details
CREATE (continued)
Users, Teams and MDBs
>- CReate -+- USer userid passwd -+--- FRee ------.

| | |
| `--- GEneral ---|
| |
|- TEam teamid ------------------------+-- DESC text ---.
| | |
| ‘----------------|
| |
‘- MDB name---------------------------------------------+-->
Querying:
>--- Query --+-- USer userid ---.

| |
|-- DB dbname -----|
| |
|-- MDB name ------|
| |
‘-- TEam teamid ---+-->
Related Commands: SET, MODULE, CHANGE, NEW

Version 11.5
Command Details
CURRENT (Project definition)
Function: Moves a DB to a given position in the current MDB list.
Description: The specified list position must be in the range 1-300.
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 -------------------->
Related Commands: ADD, REMOVE, DEFER, EXCHANGE

Version 11.5
Command Details
DADD (Project definition)
Function: Adds a DB or another DB Set to a DB Set.
Description: The DB Set must first be specified using the SET DBSET
command.
You can then give the keyword DB, followed by a list of DB names
to be added to the Set, and the keyword DBSET, followed by a list
of DB Set names to be added to the Set. The names have to be
elements of the type specified by the last keyword, but you can
use both keywords more than once in the same command line.
Examples: The following example assumes that both the Team and the DB
Set have been set using the SET command.
DADD DB /STEELN /STEELS DBSET /ASET DB /PIPEN
Adds the databases /STEELN, /STEELS and /PIPEN, and all the
Databases in the DB Set /ASET, to the current DB Set.
Command Syntax:
.----------------<------------.--<---.
/ | |
/ .----<-------. | |
/ / | | |
>-- DADD --*--- DB -------*--- dbname ---+---' |
| |
| .-------------------<------------. |
| / | |
| / .-------<-------. | |
|/ / | | |
*--- DBSET ----*--- dbsetname ---+---+---+--->
Querying: Q SET DBSET
Related Commands: DREMOVE, DELETE, SET, NEW

Version 11.5
Command Details
DEALLOCATE (Global Project Administration - Hub only)
Function: Removes databases from the list of databases allocated to a

Location.
Description: A named database or all databases can be specified. The

databases must be Secondary at the Location.
If you try to de-allocate a database from a Location which has a
Descendant Location, and the database is also allocated to the
Descendant, you will be warned of the existence of the Descendent
allocation, and no action will be taken. You must use the
INCLUDING DESCENDANTS option to de-allocate the database
from all Descendant Locations as well.
When a de-allocation command is in progress, the location is
locked against Allocate commands. This lock is set when the
Deallocate command is issued, and released by the daemon once
the database(s) have been deleted at the location. The Allocate
command can still be executed, but will stall until the full de-
allocation is complete. Locking only applies to the locations where
dBs are being deallocated, and other locations should not be
affected.
The transaction database for the location is not de-allocated when
de-allocating all databases.
See the guide Running Global Projects with VANTAGE PDMS for
more information about de-allocating databases that have
extracts.
Examples:
DEALLOCATE PIPE/PIPE AT CAM
Removes the database PIPE/PIPE from Location CAM. The database
must not exist at any Locations which are descendants of CAM.
DEALLOCATE HVAC/HVAC AT OXF INCLUDING DESCENDANTS
Removes the database HVAC/HVAC from Location OXF and all
descendants of OXF.
DEALLOCATE ALL AT LON
Removes all databases which exist at Location LON. Note that you
cannot use the INCLUDING DESCENDANTS option with ALL.

Version 11.5
Command Details
DEALLOCATE (continued)
Command Syntax:
>- DEALLOCate -+- teamid -.

| |
|----------+- dbname -+- INCluding DESCENDants -.
| | |
| `-------------------------|
| |
`- ALL -----------------------------------------+-- AT <loc> -->
Related Commands: ALLOCATE, CHANGE
Querying: At a location:
>--- Q DBALL
At a Database:
>--- Q DBLC --->

Version 11.5
Command Details
DEFER (Project definition)
Function: Makes a specified DB non-current.
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

Version 11.5
Command Details
DELETE (Project definition)
Function: Deletes elements from the project.

Note on Deleted Files
When a database is deleted, its file is renamed by addition of the
suffix .deleted. The renamed file is actually deleted on the next
SAVEWORK or module switch, once the change has been saved in
the system or global database.
This arrangement allows database files to be recovered after a
crash, by the PDMS exit handler. However, if the exit handler
cannot be invoked (for example, due to a loss of power) then the
files with the .deleted suffix can be restored manually, to make
the project directory consistent with the system or global
database.
Description: The DELETE command can be used to delete Admin elements.

The DELETE command cannot be abbreviated. This helps protect
against accidental deletion. To avoid the risk of database
corruption, all deletion of DBs (i.e. the files inside the Project
Directory) must be done from the ADMIN module and not by
using operating system utilities or commands.
Notes on Global Projects:

You can only delete Teams, Databases, Locations and Groups at
the Hub.
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 VANTAGE PDMS for further
information about deleting databases and extracts from a Global
project.
Examples:
DELETE USER
DELETE TEAM
DELETE MDB
DELETE DB
Deletes the current element of the appropriate type.
DELETE DB PIPEN/DESI
Deletes Database PIPEN/DESI
DELETE USER HVAC
Deletes User HVAC

Version 11.5
Command Details
DELETE (continued)
DELETE TEAM PIPEN

Deletes Team PIPEN
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 LOCATION LON
Deletes Location LON.
DELETE GRP
Deletes the current Location Group.
DELETE LCOMD
Deletes the current communication event.
DELETE WORKING EXTRACT FROM CTATEST/DES1 FOR USERA
Deletes the working extract for USERA from the database
CTATEST/DES1. Working extracts cannot be deleted unless the
owning extract is primary at the currently administered location.

Version 11.5
Command Details
DELETE (continued)
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 --+---------------+-->
Locations, GRPs and LCOMDs exist in Global Projects only.

Version 11.5
Command Details
DREMOVE (Project definition)
Function: Removes a DB or DB Set from the current DB Set.
Description: The DB Set must first be specified using the SET DBSET
command.
You can then give the keyword DB, followed by a list of DB names
to be removed from the Set, and the keyword DBSET, followed by
a list of DB Set names to be removed from the Set. The names
have to be elements of the type specified by the last keyword, but
you can use both keywords more than once in the same command
line.
Note that DB Sets are deleted using the DELETE command.
Examples: The following example assumes that both the Team and the DB
Set have been set using the SET command.
DREM DB /STEELN /STEELS DBSET /ASET DB /PIPEN
Removes the databases /STEELN, /STEELS and /PIPEN, and all the
Databases in the DB Set /ASET, from the current DB Set.
Command Syntax:
.----------------<------------+--<---.
/ | |
/ .----<-------. | |
/ / | | |
>-- DREMove --*--- DB -------*--- dbname ---+---' |
| |
| .-------------------<------------. |
| / | |
| / .-------<-------. | |
|/ / | | |
*--- DBSET ----*--- dbsetname ---+---+---+--->
Querying: Q SET DBSET
Related Commands: DADD, DELETE, SET

Version 11.5
Command Details
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:
>--- DUmp filename --->
Related Commands: LOAD, XREF

Version 11.5
Command Details
DUPLICATENAMES (Global Project Administration)
Function: Checks for elements with duplicate names in the Project.
Description: You can specify all Databases in the Project or a list.

The process takes place in several stages, using different
variations of the command. A typical sequence is shown in the
Examples.
Example of Command Sequence:

DUPLIC START
Initialise memory allocation etc.
DUPLIC FILE /filename
Specify file for report. If this command is not given, the report will be
sent to the screen.
DUPLIC INCLUDE ALL
Include all the Databases in the project in the check.
DUPLIC EXCLUDE DB dbname dbname ...
Exclude the named Databases from the check.
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, re-define the list of Databases you wish
to check, and give the DUPLIC CHECK command again.
Other Examples:
Other options which you can use to set up the list of Databases are as follows:
DUPLIC INCLUDE DB dbname dbname ...
Include the named Databases in the check.
DUPLIC INCLUDE CLEAR
Remove all entries in INCLUDE list
DUPLIC INCLUDE LIST
List all entries in INCLUDE list
DUPLIC EXCLUDE CLEAR
Remove all entries in EXCLUDE list
DUPLIC EXCLUDE LIST
List all entries in EXCLUDE list

Version 11.5
Command Details
DUPLICATENAMES (continued)
The output reports the element name and the DB reference

number and DB number for each of the duplicates, for example:
/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 --->

Version 11.5
Command Details
EDIT (Module definition)
Function: Enables project module entries to be edited.
Description: Enters edit mode (which continues as long as only command lines
beginning with EDIT or MODULE are used) within which a project
module entry’s NAME, NUMBER, SECURITY, MODE, data file,
RESUME file and IMACRO and BUFFER options can be edited.
Examples:
EDIT MODU ADMIN IMACRO /START
Enter EDIT mode and edits module ADMIN to add the macro /START
as an initialisation macro.
EDIT MODU 77 SECU FR
Enter EDIT mode and edits module 77 to make it a FREE module
MODU 77 MODE CATA RW
In Edit mode, change module 77 to CATA db with read/write mode.
EDIT MODU DESIGN RES /%PDMSEXE%/DES
Change resume file name for DESIGN module entry
EDIT MODU ADMIN IMACRO DELETE
Edits the ADMIN module definition and deletes the Imacro entry.

Version 11.5
Command Details
EDIT (continued)
Command Syntax:
.----------------------------------------------------------------------------.
/ |
>- EDit -*- MODule -+- number --. |
| | | |
| ‘- modname -+- NUmber number ---------------------------------------|
| | |
| |- NAme name -------------------------------------------|
| | |
| |- Security -+- FRee ------------------------. |
| | | | |
| | `- GENeral ---------------------| |
| | | |
| |- Mode file -+- RW -------------------------| |
| | | | |
| | |- Read -----------------------| |
| | | | |
| | |- None -----------------------| |
| | | | |
| | ‘- DEFault --------------------| |
| | | |
| |- Open -+- SYMBOLFILE --. | |
| | | | | |
| | |- ATTlibfile --| | |
| | | | | |
| | ‘- MESSagefile -+- name -. | |
| | | | | |
| | ‘--------+- DELETE -| |
| | | | |
| | ‘----------| |
| | | |
| |- Resume file ------------------------------| |
| | | |
| |- Buffer -+- integer -----------------------| |
| | | | |
| | ‘- DEFault -----------------------| |
| | | |
| |- Imacro -+- name ---. | |
| | | | | |
| | ‘- DELETE -+----------------------+- newline-’
| |
‘----------------------+--------------------------------------------------------->
Related Commands: MODULE, LIST MODULES, DELETE MODULES

Version 11.5
Command Details
ERRORFILE (Data Integrity Checking)
Function: Specifies the name of the file containing the error and warning
messages when DICE is used in stand-alone mode.
Description: 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
available automatically, but this is not the case in stand-alone
mode. Hence the first command you must give in stand-alone
mode is the ERRORFILE command, followed by the name of the
error message file.
The name of the message file can be found from the entry for
DICE in the current version of makemac.mac, the project
configuration macro.
Examples:
ERRORFILE /%PDMSEXE%/MESSAGE.DAT
Command Syntax:
>--- ERRORfile filename --->
Related Commands: MODULE, LIST MODULES

Version 11.5
Command Details
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:
>--- ERRors number --->
Related Commands: BRIEF, FULL, VB

Version 11.5
Command Details
EXCHANGE (Project definition)
Function: Replaces the current DB by a non-current DB.
Description: The DB names to be exchanged do not need to be listed in a

particular order, since the MDB knows which are current and
which are non-current, but they must be paired correctly if more
than two names are listed.
Examples:
EXCHANGE PIPING/AREA-A SERV/AREA-D SERV/AREA-E PIPING/AREA-B
PIPING/AREA-A and PIPING/AREA-B are the current DBs. They
will be replaced by the DBs SERV/AREA-D and SERV/AREA-E
respectively, even though they are listed out of sequence.
Command Syntax:
.--------<----------.
/ |
>-- EXchange ---*--- dbname dbname ---’
|
|-----------------------.
| |
‘--- integer integer ---+--->
Related Commands: ADD, REMOVE, CURRENT, DEFER

Version 11.5
Command Details
EXCLUDE (Project definition)
Function: Removes a database which has been included from an external

project.
In a Global Project, you can only exclude Databases at the Hub.

The database must not be allocated to any satellites.
Examples:
EXCLUDE DB MASTER/STEELCATA
Remove named DB from current project
Command Syntax:
>--- EXCLude DB dbname --->
Related Commands: INCLUDE

Version 11.5
Command Details
EXPUNGE (Project administration)
Function: Removes users who are accessing the Project, and releases
claimed elements in Multiwrite databases.
Description: This command can be used to remove phantom users after

abnormal exits. Users who are actually accessing the Project will
be removed as soon as they change module.
In a Global project, you can use this command on Constructor

databases at Locations which you administering remotely by
prefixing it with the REMOTE <loc> command, where <loc> is the
Location identifier. See the REMOTE command for examples.
In a Global project, you can use the EXPUNGE DB SYSTEM

command to expunge the current administered System database.
You will have to give the ADMINISTER SYSTEM command first
if you are administering a Location remotely.
Examples:
EXPUNGE ’29f’
Expunge user identified by given process number.
EXPUNGE
Expunge all users. (This should be used with care.)
EXPUNGE DB dbname
Releases elements which have been claimed in a multiwrite database.
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.
EXPUNGE DB dbname USER usernumber
Expunges given user from given DB. This is allowed even if there are
users accessing the DB. It is the preferred way of freeing unreleased
claims.

Version 11.5
Command Details
EXPUNGE (continued)
Command Syntax:
.-----<--------------------------------.
/ |
>-- EXPUNGE --*-- process_id --------------------------|
| |
|-- 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,

For Global projects - REMOTE, REMOTE EXPUNGE

Version 11.5
Command Details
EXTERNAL (Data Integrity Checking)
Function: Checks that all external references point to DBs of appropriate

types.
Description: 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 command, 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. This setting is used by
standalone DICE (and REMOTE CHECK).
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.
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.

Version 11.5
Command Details
EXTERNAL (continued)
Examples:
EXTERNAL CHECK
EXTERNAL NOCHECK
EXTERNAL REJECT
An example of the output when EXTERNAL CHECK is specified:
External databases referenced
_____________________________
Number Name No of references

______ ____ ________________
8 GLB/DESI 41
31 TECHP/TPDESI 4
Command Syntax:
>--- EXTernal ---+--- NOCHeck* ---.
| |
|--- CHECK ------+-- PREFERENCE
| |
‘--- REject -----+--->
The default is NOCHECK.

Version 11.5
Command Details
EXTRACT (Project administration)
Function: Control of database extracts
Description: This command allows you to release, issue, drop and refresh
extract databases.
FLUSH Writes the changes back to the parent extract. The
Extract claim is maintained. The extract is refreshed
with changes that have been made to its owning
database.
FLUSH RESET
Resets the database after a failed EXTRACT FLUSH
command. If more than one user is issuing the same
database extract, then flush and release commands
can be processed in the wrong order, causing a flush to
fail and preventing subsequent refreshes of the
extract. This command can be used to undo the failed
flush.
FLUSHW (Flush without refresh) Writes the changes back to the
parent extract. The Extract claim is maintained. The
extract is not refreshed.
REFRESH Refreshes any extract in the database hierarchy with
changes that have been made to its parent extract.
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.
ISSUE Writes the changes back to the parent extract, and
releases the extract claim.
RELEASE Releases the extract claim: this command can only be
used to release changes that have already been
flushed.
DROP Drops changes that have not been flushed or issued.
The user claim must have been unclaimed before this
command can be given.

Version 11.5
Command Details
EXTRACT (continued)
Note that unlike the constructor modules, you can only perform
these operations on a complete database in ADMIN, and so
claiming has no meaning in ADMIN. For general information
about using extracts in projects, see the VANTAGE PDMS
ADMIN User Guide. For information about using extracts in
Global projects, see Running Global Projects with VANTAGE
PDMS.
In a Global project, Flush, release and issue may be executed

remotely if the parent extract is not primary at the current
location.
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.
Examples:
EXTRACT FULLREFRESH DB PIPE/PIPE-X1
Refreshes all parent extracts in the database hierarchy above
PIPE/PIPE-X1, ending by refreshing PIPE/PIPE-X1 itself with changes
to its parent extract.
EXTRACT REFRESH DB PIPE/PIPE-X1
Refreshes database PIPE/PIPE-X1 with changes to its parent extract.
EXTRACT RELEASE DB PIPE/PIPE-X1
Releases all extract claims in database PIPE/PIPE-X1.
EXTRACT ISSUE DB PIPE/PIPE-X1
Issues all changes to database PIPE/PIPE-X1 and releases the extract
claim.
EXTRACT FLUSH DB PIPE/PIPE-X1
Writes the changes to database PIPE/PIPE-X1 back to its parent
extract, but keeps the elements claimed to the extract.
Also, PIPE/PIPE-X1 is refreshed with changes to its owning database.
EXTRACT FLUSHW DB PIPE/PIPE-X1
Writes the changes to database PIPE/PIPE-X1 back to its parent
extract, but keeps the elements claimed to the extract. PIPE/PIPE-X1
is not refreshed.
EXTRACT DROP DB PIPE/PIPE-X1
Drops all changes to database PIPE/PIPE-X1.

Version 11.5
Command Details
EXTRACT (continued)
EXTRACT FLUSH RESET DB PIPE/PIPE-X1

Undoes a failed flush on this database.
Command Syntax:
>-- EXTRACT -+- 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.

Version 11.5
Command Details
FINISH (General PDMS Command)
Function: The FINISH command saves work and leaves PDMS.

Examples:
FINISH
Command Syntax:
>--- FINISH --->
Related Commands: SAVEWORK

Version 11.5
Command Details
FONTDIRECTORY (Font definition)
Function: Sets the font directory name.
Description: The font directory stores the font families for use in DESIGN and
DRAFT. Font families are defined by the FONTFAMILY
command. The FONTDIRECTORY command can be given in
ADMIN or used in the make macro. In the make.mac macro
supplied the font directory is defined as %PDMSEXE%. If the font
directory is unset, PDMS will search for the fonts in the user’s
current directory.
Examples:
FONTD /%PDMSEXE%
Command Syntax:
>--- FONTDirectory name --->
Querying: >--- Q FONTDirectory --->
Related Commands: FONTFAMILY, Q FONTS

Version 11.5
Command Details
FONTFAMILY (Font definition)
Function: Defines a font family.
Description: Defines a font family in terms of a character set and a style, or in

terms of a file. If a file is specified, a bold version of the same font
family can also be specified. Sloping text can be produced.
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).
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

Version 11.5
Command Details
FONTFAMILY (continued)
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 --|
| |
`------------+-->
Notes:
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
Querying: >--- Q FONTFamily integer --->

Version 11.5
Command Details
FROM (Reconfiguration)
Function: Specifies the source database for reconfiguration.
Examples:
Source data is in database MASTER/DESIGN in current project
FROM DBFILE /des016
Source data is in specified file (assumes project directory is current
directory)
FROM PROJECT des MASTER/DESIGN
Source data is in specified DB within project des
FROM FORMATTEDFILES /F1 /F2
Source data is in named character-format intermediate files (used
when transferring data between computers).
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 ---+-->
Related Commands: RECONFIG, RCFCOPY, TO

Version 11.5
Command Details
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:
>--- FUll --->
Related Commands: BRIEF, VB, ERRORS

Version 11.5
Command Details
GENERATE (Global Project Administration - Hub only)
Function: Generates the files required for a new location.
Description: All the Project files are copied to a transfer directory at the Hub,
ready for transmission to the new satellite. The transfer directory
is specified by the environment variable
project_locid
where project is the 3-character project code and locid is the 3-
character identifier of the new location.
Before the command is given, the environment variable must be
set, the transfer directory must exist and contain the normal
project sub-directories, and the transaction database for the
location must already have been created. The project Hub should
have already been initialised (or its LINIT attribute set True).
All the files in the Project will be copied to the transfer area. They
must then be transferred to the Location before the Location is
initialised.
After a LOC element has been created for a new Location, the
LOCID and LOCREF must be set. The LOCID assigns a unique
three-character code to the new Location. The LOCREF defines
the position of the new Location within the network by specifying
its unique parent Location.
This command sets the LINIT flag for an offline Location. The
LINIT flag must be set by the INITIALISE command for an on-
line Location.
If the ALLOCATE option is specified, all the Databases allocated
to the Location’s Parent will be allocated to the new Location as
well. The NOALLOCATE option means that no databases (other
than its transaction database) will be allocated to the new
Location: no database files will be copied to the transfer area.
Note that a transaction database must have been created for the
location (and for the Hub), and the Hub must have been
initialised.

Version 11.5
Command Details
GENERATE (continued)
Examples:
GENERATE LOCATION LON
Generates a location with identifier LON. By default, all Databases at
the Hub will be allocated to LON.
GENERATE LOCATION /LONDON
Generates a location /LONDON, allocating all databases.
GENERATE LOCATION LON NOALLOCate
Generates a location with identifier LON. No Databases will be
allocated.
Note: If the location identifier contains numeric characters, it
must be enclosed in quotes.
Command Syntax:
>-- GENerate LOCation <loc> --+--- ALLOCate -----.

| |
`--- NOALLOCate ---+-->
Related Commands: INITIALISE
For Offline locations: TRANSFER
Querying: >--- Q LINIT --->

>--- Q DBALL --->

Version 11.5
Command Details
GETWORK (General PDMS Command)
Function: Refresh view of System database, if there is more than one

ADMIN user.
In Global projects, this command must be given before you can

see changes made to the Global and Transaction databases by the
Global daemon. For detailed information about when GETWORK
commands are necessary, see Running Global Projects with
VANTAGE PDMS.
Command Syntax:
>--- GETWORK --->
Related Commands: SAVEWORK

Version 11.5
Command Details
HUBLOCATION (Global Project Administration - Hub only)
Function: Relocate Project Hub.
Description: The specified Location becomes the new Hub.
The Location which will become the new Hub must have all DBs
allocated to it using the ALLOCATE ALL …OVERRIDE PROPG
command before the HUBLOCATION command is given. (The
OVERRIDE PROPG option ensures that non-propagating
databases, including transaction databases are allocated to the
new hub)
You may also wish to give a SYNCHRONISE command at the
Location which will become the Hub to bring the databases up-to-
date. You are advised to backup the Global database at the Hub
before issuing this command.
The relocation can be deferred until a given time (for online
Locations only).
Note: Before you give this command, the new Hub Location
must have a locally administered System database, and
all constructor databases must be allocated to it (see
above). You must wait for the operation to complete: see
the VANTAGE Plant Design Global User Guide for more
information on Hub administration.
If a HUBLOCATION command fails, the previous Hub will
normally be recovered automatically. If the recovery fails (for
example, the daemon is not running), you can recover the
PREVOWN HUB
Examples:
HUBLOCATION LON
Relocates the Hub to location with identifier LON.
HUBLOCATION LON AT 20:00
Relocates the Hub to location with identifier LON at 2000 hrs.

Version 11.5
Command Details
HUB LOCATION (continued)
Command Syntax:
>--- HUBLOCation <loc> ---+-----------------.

| |
`--- AT <time> ---+--->
Related Commands: PREVOWNER HUB, ALLOCATE ALL
Querying: >--- Q HUBRF --->

Version 11.5
Command Details
INCLUDE (Project definition)
Function: Includes databases from another project in the current MDB.

Note that the external databases can only be accessed in Read-
only mode.
In a Global Project, you can only include Databases at the Hub.
Description: Included databases are also known as foreign databases. They are
often used for sharing Catalogues.
When creating a new Project that is required to share DBs from
other Projects, there are two important considerations:
• Teams must exist for all DBs that are to be shared.
• DBs in the source project that are to be shared should not be
given a DB number that will clash with a DB number that
already exists in the destination project.
Examples:
INCLUDE DB MASTER/PIPECATA FROM PROJ MAS USER USERA/A
The database MASTER/PIPECATA from project MAS will be included
in the current project. The user/password (USERA/A in this example)
must be a FREE user in the source project.
Command Syntax:
>--- INCLude DB dbname FROM PROject projectid USer username/password --->
Related Commands: CNAME, MOVE, CHANGE, EXCLUDE, COPY

Version 11.5
Command Details
INITIALISE (Global Project Administration)
Function: Initialise communications link at an on-line Location.
Description: This command checks for the existence of the Admin daemon at
the given location and informs the Hub that the location is on-
line. The command must be given at the Location after the files
generated by the GENERATE LOCATION command have been
transferred to the Location, and the Admin daemon has been
started at the Location.
Locations must be initialised before any Global activities can take
place.
Note that this command is only needed for online Locations: the
LINIT attribute of an offline Location is set to TRUE by the
GENERATE LOCATION command.
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:
>--- INITIALise --->
Related Commands: GENERATE LOCATION
Querying: Q LINIT

Version 11.5
Command Details
ISOLATION (Global Project Administration)
Function: Isolates a Location so that no updates take place.
Description: An isolated Location will not accept database updates from other
Locations, or transfer updates to other Locations. Note that User
messages and queries are accepted, and some commands can be
passed through an isolated Location.
A Location may need to be isolated if data corruption is suspected.
Isolation commands are not recorded in the transaction database.
Examples:
ISOLATION TRUE
Isolates the current Location.
ISOLATION FALSE
Connects the current Location.
ISOLATION TRUE AT LON
Isolates the remote Location LON. This command is only available at
the Hub or at the administering location (in this example, that for
LON).
ISOLATION FALSE AT LON
Connects the remote Location LON. This command is only available at
the Hub or at the administering location (in this example, that for
LON).
Command Syntax:
>--- ISOLATion ---+--- TRUE ----.

| |
`--- FALSE ---+--- AT <loc> ---.
| |
`----------------+--->
Querying: >--- Query ISOLATion ---+--- AT <loc> ---.

| |
`----------------+--->

Version 11.5
Command Details
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 DBS OF TYPE DESI
Lists all the Databases of type DESI 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 filenames in the
Project directory.
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 MODULES DESIGN
Produces information on module DESIGN.
LIST MESSAGES
Lists inter-user messages.
LIST PASSWORDS
Lists users’ ids and passwords.
LIST TYPES
Lists the types of DB currently permissible.

Version 11.5
Command Details
LIST (continued)
LIST SIZES
Gives the sizes of all the DBs in a project.
LIST EXTERNAL
Lists DBs which are being shared with another project.
LIST MACROS
Lists inter-db connection macros.
LIST AREA 51
Lists DBs in Project Area 51.
LIST WORKing EXTracts
Lists the working extracts.
LIST WORKing EXTracts FOR user
Lists the working extracts for the specified user.
LIST WORKing EXTracts dbname
Lists the working extracts for the specified DB.

Version 11.5
Command Details
LIST (continued)
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 ----------------------------------|
| |
‘--- WORKing EXTracts –-+----------.- FOR user -+--->
| |
‘- dbname –’
Related Commands: QUERY

Version 11.5
Command Details
LOAD (Reconfiguration)
Function: Loads the reference number index from the given file.
Examples:
LOAD /DUMP1
Read reference number index from named file and replace current
index.
LOAD /DUMP1 APPEND
Read reference number index from named file and
append to current index.
Command Syntax:
>--- LOad ---+--- APPEND ---.
| |
‘--------------+--- filename --->
Related Commands: DUMP, REINIT, XREF

Version 11.5
Command Details
LOCK (Project administration)
Function: Locks the Project Database and prevents any other user from
entering the database until the project is unlocked.
In a Global Project, a Project Database can be locked remotely

from the Hub.
Description: LOCK has no effect on users already accessing a project; it simply

prevents people from entering that project. If the System
Administrator is planning to execute a major change, particularly
if he is to incorporate new versions of modules, he should first
LOCK the project, then send a message to all users asking them
to leave PDMS, make the required changes when there are no
users left actively in the project, and finally UNLOCK it.
Locking and Unlocking commands are not recorded in the
Examples:
LOCK
Locks the Project database.
LOCK AT LON
Locks 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:
>--- LOCK ------>
Related Commands: UNLOCK
Querying: >--- Query LOCK --->
Only available at Hub of a Global Project or at the administering

location:
>--- Query LOCK ---+--- AT <loc> ---.

| |
`-----------------+--->

Version 11.5
Command Details
MAKE GLOBAL (Global Project Administration)
Function: Make a standard Project into a Global Project.
Description: This command splits the System database, creating a local

System database and a Global database. This format is suitable
for distribution to several geographical places. The Project
becomes a Global Project with one Location, the Hub.
The Project should be locked before the MAKE GLOBAL command
is issued, and unlocked afterwards.
Warning:
This command should be used with care, as it
alters the structure of the System database. This
process cannot be reversed using PDMS. You are
advised to take a full backup of your Project before
proceeding.
For details of Global Project Administration, see the VANTAGE
PLANT DESIGN Global User Guide.
Examples:
MAKE GLOBAL
Command Syntax:
>--- MAKE GLOBAL --->

Version 11.5
Command Details
MAXERRORS (Data Integrity Checking)
Function: Specifies the maximum number of errors found before data

integrity checking is abandoned.
Note: This command should only be used when running DICE
in stand-alone mode (or REMOTE CHECK). For DICE
checking within a PDMS project, use the CHECKOPTION
command.
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 --->

Version 11.5
Command Details
MAXUSERS (Project Administration)
Function: Sets the maximum number of users for a project. Note that there
is no theoretical limit to the number of simultaneous users, but a
limit may be set by the current licence restrictions.
Examples:
MAXUSERS 10
Command Syntax:
>--- MAXUSers integer --->

Version 11.5
Command Details
MAXWARNINGS (Data Integrity Checking)
Function: Specifies the maximum number of warnings found before data

integrity checking is abandoned.
command.
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 is 50.
Example:
MAXWARNINGS 100
Related Commands: MODE, MAXERRORS
Command Syntax:
>--- MAXWarnings integer --->

Version 11.5
Command Details
MERGE CHANGES (Project Administration)
Function: Merges the changes made to a database over several sessions.
In a Global Project, this command can only be carried out when

you are administering the Primary Location of a Database.
Description: Sessions are defined as the work done between SAVEWORK

commands. They allow you to track the changes made to a
database. If you are not interested in the history, or you want to
save disk space, you can merge the changes made in several
sessions.
In a Global project, you can use this command to merge changes

in databases which are Primary at a remote Location by prefixing
it with the REMOTE <loc> command, where <loc> is the Location
identifier. See the REMOTE command for examples.
After you merge changes, some session data is deleted. The
sessions remaining are those that you have either kept
deliberately, or stamped sessions, as these cannot be merged.
Note: If a database owns an extract database, you cannot merge
the linked session, that is the session which was current
when the extract was created.
Note: In a Global project, spurious ‘lost bucket’ errors may be

reported on the master database if there are working
extracts at other locations.
Examples:
MERGE CHANGES HVAC/PADD AFTER SESSION 4 BEFORE SESSION 10
Merges all the changes to the HVAC/PADD database after session 4
and before session 10, that is all changes made in sessions 5 to 9 will be
combined. If there are any stamped sessions in sessions 5 to 9, they
will be kept. The team id (HVAC) can be omitted if a current team is
set.
MERGE CHANGES HVAC/PADD AFTER STAMP /
stamp_012 BEFORE STAMP /stamp_016
Merges all the changes to the HVAC/PADD database for sessions that
are after the session stamped with stamp_012 and before the session
stamped with stamp_016. All changes made in stamped sessions that
are between the sessions stamped with stamp_012 and stamp_016 will
be combined. If there are any other stamped sessions, they will be kept.
The team id (HVAC) can be omitted if a current team is set.

Version 11.5
Command Details
MERGE CHANGES (continued)
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.
MERGE CHANGES PROJECT
Merges all the changes to all databases in the project, except stamped
sessions. A range of dates may be specified, but not a session number.
Merges all the changes to the System database. A date, session number
or stamp cannot be specified. In a Global project, you must be
administering the System database and be at its primary location.
MERGE CHANGES GLOBAL
This command is only available in a Global project, at the Hub. Merges
all the changes to the Global database. A date, session number or
stamp cannot be specified.
Command Syntax for Standard (Non-Global) project:
>- MERGE CHANGES -+- team -.

| |
|--------+- db -.
| |
|- PROJECT -----AFTER ----.
| | |
| `---------+- <when> -.
| | |
| ‘-----------+- BEFORE -.
| | |
| ‘----------+- <when> ->
|
|--- SYSTEM ------------------------------------------->|
Note: <BEFORE/AFTER> do not apply to the <SYSTEM db>

Version 11.5
Command Details
MERGE CHANGES (continued)
Command Syntax for Global project:
>- MERGE CHANGES -+- team --.

| |
|---------+- db -.
| |
|--- PROJECT ----+- AFTER -.
| | |
| `---------+-- when -.
| | |
| ‘---------+- BEFORE -.
| | |
| ‘----------+- when -.
| |
|--- SYSTEM ---------------------------------------------|
| |
‘--- GLOBAL ---------------------------------------------+-->
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
Section 7.2, 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

Version 11.5
Command Details
MESSAGE (Project administration)
Function: Sends messages to other users.
Description: Can be used to send a message, of up to 80 characters, to one of

the following:
• An individual user, specified by name, number or login
name
• Users on a specified workstation
• All members of a specified team
• All active project users
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’
Command Syntax:
>--- MEssage ----+--- ID text ------- text ----------.

| |
|--- USer userid --- text ----------|
| |
|--- TEam teamid --- text ----------|
| |
|--- HOST ---------- text ----------|
| |
|--- LOGIN --------- text ----------|
| |
‘------------------- text ----------+-->
Querying: LIST MESSAGE
Related Commands: DELETE MESSAGE,

REMOTEMESSAGE (Global Projects only)

Version 11.5
Command Details
MODE (Data Integrity Checking)
Function: Specifies what happens when DICE finds an error.

command.
Description: There are two types of DB fault detected by DICE:

• An error is identified if the DB is corrupted internally.
• 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 commands,
respectively.
Examples:
MODE BRIEF
MODE FULL
Related Commands: MAXERRORS
Command Syntax:
>--- MOde ---+--- BRief ---.

| |
‘--- FUll ----+--->
The default is BRIEF.

Version 11.5
Command Details
MODULE (Module Definition)
Function: Creates an entry for a module in the System DB.
Description: Command includes a variety of options, enabling the parameters

of the runfile (the file containing the binary version of the module
software) to be specified. The options are specified by the
following keywords:
OPEN specifies a data file which the module is expecting to have

opened for it.
MODE specifies the modes (Read, Read/Write etc.) in which the

various types of DB comprising the current MDB are to be
opened.
RESUME specifies the name of the runfile of the module to be

used for this project.
SECURITY specifies the security rating of the module.
BUFFER specifies how much space is to be reserved for the

DABACON buffer.
IMACRO specifies the name of an initialisation macro.
The above options may be entered in any order, and may be

repeated any number of times.
Examples:
Module 78 DESIGN
Security Free
Mode DESI Default
Mode PROP R
Mode CATA R
Mode DESI RW
Resume /%PDMSEXE%/des
Command Syntax:
>--- MODule ---+--- integer module_name ---.

| |
‘--- module_name integer ---+--- newline <runf> -->

Version 11.5
Command Details
MODULE (continued)
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 --+--->

Version 11.5
Command Details
MOVE (Project administration)
Function: Moves a DB to a different directory.
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:
MOVE DB HVAC/HVAC TO AREA 051
Command Syntax:
>--- MOve DB dbname TO AREA integer --->
Related Commands: CNAME, CHANGE, INCLUDE, EXCLUDE

Version 11.5
Command Details
NEW (Project definition and Global Project Administration)
Function: Create an ADMIN element.
Description: This command is used:

• In any Project, to create Roles, Scopes, Teams, DB Sets and
MDBs. In a Global Project, Roles can only be created at the
Hub. Roles, PEROPs and Teams must be created in the
global database.
• At the Hub of a Global project, to create the Global

elements of Locations, Location Groups and Communication
Events (LCOMDs).
Examples (any Project):

NEW ROLE /SnrPiper
Creates a new Role named SnrPiper.
NEW PEROP /MaxBore
Creates a new Permissible Operation named MaxBore. The current
element must be a Role.
NEW SCOPE /AREA-A
Creates a new Scope named Area-A.
NEW DBSET /ASET-A
Creates a new DB Set named ASET-A
NEW ACR /ACR-A
Creates a new ACR named ACR-A
NEW ACRST /ACRSET
Creates a new DB Set named ACRSET
Note: After creating these elements, you will need to set their
attributes. See Chapter 4.

Version 11.5
Command Details
NEW (continued)
Command Syntax (any Project):
>--- NEW ---+--- ROLE /name ----.

| |
|--- PEROP /name ---|
| |
|--- SCOPE /name ---|
| |
|--- TEAM /name ----|
| |
|--- ACR /name -----|
| |
|--- ACRST /name ---|
| |
|--- MDB /name -----|
| |
`--- DBSET /name ---+--->
Examples (at the Hub of a Global project):

NEW LOCATION /CAMBRIDGE
Creates a new location named CAMBRIDGE.
NEW GRP /AUSTRALIA
Creates a Location Group named AUSTRALIA.
NEW LCOMD /NORMAL
Creates a Communications Event named NORMAL.
NEW LCTIMD /EVENTS/NORMAL
Creates an Events timing element named EVENTS/NORMAL.
Command Syntax (at the Hub of a Global project):
>--- NEW ---+--- LOC /name -----|

| |
|--- GRP /name -----|
| |
|--- LCOMD /name ---|
| |
`--- LCTIMD /name --+--->
Related Commands: CREATE

Version 11.5
Command Details
NEW STAMP (Project administration)
Function: Creates a new stamp element.
Description: This command allows you to create a stamp to be used to mark

database sessions. You can stamp sessions, either by a specific
time and date, or by session number. Once you have stamped
database sessions, you can use the stamp name in commands
where a date or session number can be used, such as
BACKTRACK or REVERT. Stamping database sessions makes it
easier for you to:
• make comparisons and identify changes made from session
to session – for example, you can issue drawings on which
all revisions that have been made since an earlier stamped
session are highlighted
• merge database sessions
• backtrack a standard database to a previous session
• revert an extract database to a previous session
In a Global project, stamps must be created at the Hub
Example:
NEW STAMP /Stamp_007
Creates a new stamp named Stamp_007.
NEW STLST STLSF /*PIPEDB STSESS 7
Creates a new Stamp List for each DB in the stamp (here, PIPEDB),
for session number 7. The Stamp List holds a reference to the DB and
the session number. Any number of STLST elements can be created (or
deleted). The default value of STSESS is the current session for the
DB.
Command Syntax:
.--------<---------.
/ |
>-- NEW --+-- STLST --*-- STLSF /*dbname –-'--+-- STSESS dbname ---.
| | |
| ‘ |
| |
‘-- STAMP /stampname ------------------------------------+--->

Version 11.5
Command Details
NEW STAMP (continued)
Related Commands: BACKTRACK, MERGE CHANGES, REVERT
Querying: >--- Query attribute --->

where the current element is a stamp.

Version 11.5
Command Details
PING (Global Project Administration)
Function: Checks that the communications link to named Location exists.
Description: A round-trip time will be displayed.
Example:
PING LON
Checks that communications link to Location LON exists.
Command Syntax:
>- PING <loc> --->
Related Commands: Q COMMS

Version 11.5
Command Details
PREVOWNER (Global Project Administration - Hub only)
Function: Restores the Hub to its previous Location, or restores the previous
Primary Location of a database, if the commands to change these
attributes have failed.
CAUTION: This command should not be used, except

under special circumstances (see below).
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 location’s 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.

Version 11.5
Command Details
PREVOWNER (continued)
Examples:
PREVOWNER HUB
PREVOWNER dbname
PREVOWNER SYSTEM AT <loc>
Command Syntax:
>--- PREVOwner ---+--- HUB ---------------.

| |
|--- SYSTEM AT <loc> ---|
| |
`--- dbname ------------+--->
Related Commands: HUBLOCATION, SYSTEMLOCATION, CHANGE PRIMARY
Querying: >--- Query PRVRF --->

This query must be used at the appropriate element. For
CHANGE PRIMARY, this is DBLOC 1 of <dbname>; for
SYSTEMLOCATION, this is <loc>; for HUBLOCATION, this is
/*GL.
>--- Query NXTHB --->

If a problem occurs with the HUBLOCATION command, you can
use this query at /*GL to query NXTHB. NXTHB is used to
record the future new Hub until the HUBLOCATION command
has completed.

Version 11.5
Command Details
PROJECT (Project definition)
Function: Adds descriptive information to project definitions. Also used to

set Multibyte characters sets for fonts such as Kanji. You can,
optionally, specify a second (bold) user-defined font file for
multibyte fonts.
In a Global Project, the Name, Description, Number and

MBCHARSET can only be set at the Hub. The Message can be set
at all Locations.
Description: The descriptive information will be displayed each time the

project is entered. The attributes which can be set, with their
maximum number of characters, are:
NAME 119 characters
DESCRIPTION 119 characters
MESSAGE 119 characters
NUMBER 16 characters
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.
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

Version 11.5
Command Details
PROJECT (continued)
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 ------+-->

Version 11.5
Command Details
PURGE (Project Administration and Global Project Administration)
Function: In a Global Project, removes old database files and picture files
after propagation or transfer to an offline Location. Also removes
old picture files from any Project.
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:
PURGE OLD FILES
Deletes all files in the Project with the suffix .admold.
PURGE OLD FILES DB
Deletes all database files in the Project with the suffix .admold.
PURGE OLD FILES PICTURE
Deletes all picture files in the Project with the suffix .admold.
Command Syntax:
>--- PURGE ---+--- OLDfiles ---+----------------.

| | |
| |--- DB ---------|
| | |
| `--- PICture ----|
| |
`--- DB dbname -------------------+--->
Related Commands: TRANSFER

Version 11.5
Command Details
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.
Examples:
Q COPIES PIPING/AREA-A
List the copies of DB PIPING/AREA-A
Q SET MDB
Q SET TEAM
Q SET DBSET
Query the set (i.e. current) Team, MDB or DB Set
Q MOD DESIGN DRAFT 33
Query module entries for DESIGN, DRAFT and module 33
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 SESSIONS ON date dbname
Q SESSIONS SINCE n dbname
Q SESSIONS LAST n dbname
Query session information on a specified database
Q SESSIONS SINCE n
Q SESSIONS LAST n
Q SESSIONS ON date
Query session information on the current database (i.e. System or
Global database)
Q ACTIVE
Gives the active session number

Version 11.5
Command Details
QUERY (continued)
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.
Q ELCCNT
At a DB element, gives the extract list changes count. This value
increases when extracts are inserted or removed.
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 VANTAGE 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 COMMS LON INPUTPACKETS
Q COMMS LON OUTPUTPACKETS
Query data from comms link to location LON: Input or Output Packets.

Version 11.5
Command Details
QUERY (continued)
Q COMMS LON INPUTRequests

Q COMMS LON OUTPUTRequests
Query data from comms link to named location: Input or Output
Requests.
Q COMMS TO LON PATH
Query Comms routing to location LON.
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.
Q ISOLAT AT LON
Returns TRUE if the location LON is isolated.
Q LOCK AT LON
Returns the lock at location LON.
The following options are only available in a Global Project at the
Hub.
The daemons must be running.
Q READERS HVAC/HVAC AT CAM
Outputs a list of readers of database HVAC/HVAC at Location CAM.
Q READERS HVAC/HVAC AT CAM COUNT
Outputs a count of readers of database HVAC/HVAC at Location CAM.
Q WRITERS HVAC/HVAC AT CAM
Outputs a list of writers to database HVAC/HVAC at Location CAM.
Q WRITERS HVAC/HVAC AT CAM COUNT
Outputs a count of writers to database HVAC/HVAC at Location CAM.

Version 11.5
Command Details
QUERY (continued)
Command Syntax:
>- Q --+--- 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 ----------------+--->

Version 11.5
Command Details
QUERY (continued)
The following options are only available in a Global Project.
>--- Q COMMS ---+--- TO ---.

| |
`----------+--- <loc> ---+--- INPUTPackets ----.
| |
|--- OUTPUTPackets ---|
| |
|--- INPUTRequests ---|
| |
|--- OUTPUTRequest ---|
| |
|--- PATH ------------|
| |
`---------------------+-->
>--- Q ADMLOC --->
>--- Q CURLOC --->
>--- Q ISOLAT AT <loc> --->
>--- Q LOCK AT <loc> --->
>--- Q --+-- READERS --.

| |
`-- WRITERS --+- <dbname> --.
| |
`-------------+--- AT <loc> --.
| |
`---------------+-- COUNT --.
| |
`-----------+-->
Related Commands: LIST

Version 11.5
Command Details
RCFCOPY (Reconfiguration)
Function: Defines the part of the database to be copied from the source DB
to the destination DB before reconfiguration.
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.
RCFCOPY /SITE5A /SITE7
Copies just the named elements
Command Syntax:
.-------------<---------------------.
/ |
>--- RCFCopy ---*--- ALL --------------. |
| | |
|--- CATalogue --------| |
| | |
|--- SPECifications ---| |
| | |
|--- name -------------| |
| | |
`--- refno ------------+--- AND ------|
| |
|--- comma ---’
|
`--- INto ---+--- name ----.
| |
‘--- refno ---+--->

Version 11.5
Command Details
RCFCOPY (continued)
Querying: Q COPIES
Related Commands: FROM, TO, RECONFIG

Version 11.5
Command Details
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 MDB /USERA
Updates references to the reconfigured DB from all appropriate DBs in
MDB /USERA
RCFUPDATE TEAM STEEL
Updates references to the reconfigured DB from all appropriate DBs
owned by team STEEL.
RCFUPDATE ALL
Updates references to the reconfigured DB from all databases in
current project.
Command Syntax:
>--- RCFUPdate ---+--- DB dbname -------.

| |
|--- MDB mdbname -----|
| |
|--- TEam teamname ---|
| |
|--- ALL -------------|
| |
‘---------------------+-->
Related Commands: RECONFIGURE

Version 11.5
Command Details
RCFUPGRADE (Reconfiguration)
Function: This command is used when an upgrade to a new version of

PDMS is required.
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 ---+-->

Version 11.5
Command Details
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, GLOBAL or
COMPARATOR 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.

Version 11.5
Command Details
RECONFIGURE (continued)
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 Chapter 3, Reconfiguration.
• In a Global Project, the TO NEW option is only valid at the
Hub (see the TO command).
• 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 VANTAGE 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 ---+--->
Related Commands: FROM, TO, RCFCOPY,

RENEW (Global project only)

Version 11.5
Command Details
RECOVER (Global Project Administration)
Function: Recovers data when a database has been corrupted.
Description: This command can be used on both Primary and Secondary

databases, but for Primary databases it may be better to restore
the database from the latest backup copy, because the copies at
other Locations may not be up-to-date.
For a Primary database, by default recovery will be made from
the most recent session at a neighbouring (parent/child)
Database. For a Secondary database, by default recovery will be
made from the neighbouring database which is first on the route
to the Primary database.
Both Locations must be on-line.
Notes:
The Global database cannot be recovered using the daemon.
If the System database for a location is corrupt, it cannot be
recovered using the daemon, since the daemon needs to use
the system database to understand the network. The
System Administrator must copy this database to the
required locations outside PDMS.
When Reconfiguring or Renewing a database, you should
then recover the database at all its secondary locations in
order to prevent reverse propagation.

Version 11.5
Command Details
RECOVER (continued)
Examples: The examples are based on the following configuration:
This is the Hub

AAA
BBB
EEE
STEELN/STEEL
You are here
N is Primary at
EEE
CCC
PIPEN/PIPEN
is Primary at
You are CCC
administering
DDD from CCC DDD
Secondary constructor DBs

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
RECOVER STEELN/STEELN FROM DDD
Recovers from DDD.
Remote recovery of secondary constructor DBs
(available from the Hub or the administering location of
the satellite)
RECOVER STEELN/STEELN AT DDD
Recovers from CCC, the only neighbouring Location in this case. If
there was a child of DDD, the recovery would be from the most recent
copy.
RECOVER STEELN/STEELN AT DDD FROM BBB
Recovers DB at DDD from BBB

Version 11.5
Command Details
RECOVER (continued)
System DBs
RECOVER SYSTEM FOR EEE FROM BBB
Recovers System database for EEE from the copy at BBB.
RECOVER SYSTEM FROM BBB
Recovers System database for the true current location from BBB.
Remote recovery of System DBs
(available at the Hub or the administering location of the
satellite)
RECOVER SYSTEM FOR EEE AT AAA FROM BBB
Recovers AAA's copy of the System database for EEE from the copy at
BBB.
Command Syntax:
>--- RECOVer -+-- SYSTEM --+-- FOR <loc> --.
| | |
| `---------------|
| |
`-- dbname ------------------+-- AT <loc> --.
| |
`--------------+-- FROM <loc> --.
| |
`----------------+--->

Version 11.5
Command Details
REINIT (Reconfiguration)
Function: Re-initialises the reference number index.
Description: Re-initialises the reference number index in database

reconfiguration.
Command Syntax:
>--- REinit --->
Related Commands: DUMP, LOAD

Version 11.5
Command Details
REMOTE (Global Project Administration)
Function: Allows the Hub or the Administering Location of a Satellite to

carry out the following tasks for constructor or system databases
at a Satellite:
BACKTRACK
REVERT
MERGE CHANGES
EXPUNGE
CHECK
Other than when the REMOTE . . . CHECK command is used, the
databases must be primary at the destination Satellite.
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.
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.

Version 11.5
Command Details
REMOTE (continued)
• 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).
REMOTE…MERGE 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.
You are advised to stop scheduled updates and avoid adhoc
updates until the entire REMOTE…MERGE 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 stand-alone
DICE on the specified database from the daemon at the
specified location and reports back to the location that issued
the command.
• You can also query information about the project status at a
Satellite. See Querying below.
• REMOTE…EXPUNGE 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.
• REMOTE…MERGE and REMOTE…BACKTRACK are not
valid for extracts which own other extracts. However,
REMOTE…REVERT and REMOTE…EXPUNGE can be
used. A database that owns extracts can be merged in PDMS
using the MERGE command.

Version 11.5
Command Details
REMOTE (continued)
Examples:
For details of time and date syntax, see Section 7.2.
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 AFTER 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.
REMOTE <loc> MERGE CHANGES SYSTEM
Merges changes to the system database for the location <loc>.
REMOTE <loc> MERGE CHANGES SYSTEM FOR <loc2>
Merges changes to the system database for <loc2>, which must be
administered by <loc>.
EXPUNGE
REMOTE <loc> EXPUNGE
REMOTE <loc> EXPUNGE username
Expunges all users or the given user from the communications
database at the given Location. username is the PDMS username.
REMOTE <loc> EXPUNGE DB dbname
REMOTE <loc> EXPUNGE DB dbname USER username
REMOTE <loc> EXPUNGE DB SYSTEM
REMOTE <loc> EXPUNGE DB SYSTEM FOR <loc2>
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.

Version 11.5
Command Details
REMOTE (continued)
DICE Checking
REMOTE <loc> CHECK SYSTEM
REMOTE <loc> CHECK DB dbname
REMOTE <loc> CHECK MISCDB dbname
REMOTE <loc> CHECK COMMDB
REMOTE <loc> CHECK SYSTEMDB FOR <loc2>
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
REMOTE <loc> CANCEL <gid>
Allows an Admin user to cancel a command at another Location <loc>,
where <gid> is a TRINCO in the transaction database for the given
Location (this is not the current Location, unless <loc> is the current
Location). This command requires an up-to-date version of the
transaction database for Location <loc> to be available at the current
Location. (The transaction database is not normally propagated. It is
best to RECOVER this database from the primary location rather than
to SYNCHRONISE it.)
Command Syntax:
• For details of <loc> and <when> syntax, see Section 7.2.
>- REMOTE <loc> BACKTRACK dbname TO <when> -->
>- REMOTE <loc> REVERT dbname TO <when> -->
>- REMOTE <loc> MERGE CHANGES -+- dbname ----------------+-<when>-->

|
`- SYSTEM -+- FOR <loc2> -+-->
| |
`--------------+-->

Version 11.5
Command Details
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

Version 11.5
Command Details
REMOTE (continued)
Querying:
Remote database session information can only be queried by
looking at the secondary database at the current location, which
may not be up-to-date.
Information about remote users of PDMS may be queried using
remote session objects. For example
!p = current project Returns a PROJECT object
!l = !p.locations() Returns an array of LOCATION
objects
!r = !l[2].sessions() Where !l[2] is not the current
location, returns an array of
SESSION objects
q var !r[1]
q var !r[1].module() Returns data about a given
session
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
REMOTE…EXPUNGE.
For more information about PML Objects see the Plant Design
Software Customisation Reference Manual. Only these three
session methods are available for remote sessions.

Version 11.5
Command Details
REMOTEMESSAGE (Global Project Administration)
Function: Sends messages to users at other Locations.
Examples:
REMOTEMessage <loc> ALL text
Send message to all users at named location
REMOTEMessage <loc> TEAM teamid text
Send message to all members of a team at named location
REMOTEMessage <loc> FREEUSER text
Send message to administrator at a named location
Command Syntax:
>--- REMOTEMessage <loc> ---+--- ALL -----------.

| |
|--- FREEuser --------|
| |
`--- TEam teamid -----+--- text --->
Related Commands: MESSAGE, LIST MESSAGE
Querying: >--- Query DBALL --->

Version 11.5
Command Details
REMOVE (Project definition)
Function: Removes the specified DB from the MDB.
Examples:
REMOVE SERV/AREA-D
Command Syntax:
.------------.
/ |
>-- REMove dbname ---*--- dbname ---’
|
‘-------------------->
Related Commands: ADD, REMOVE, CURRENT, DEFER

Version 11.5
Command Details
RENEW (Global Project Administration)
Function: Deletes a transaction database and creates a fresh version.
Description: If a transaction database becomes corrupt, it may be necessary to

delete it and then re-create it. Existing commands in the database
may be retained by Reconfiguring to file before the Renew and
from file after the Renew.
This daemon command is availabe with two options, namely

DELETE and AT. It deletes an existing transaction database file
at a Location and creates a fresh version.
The RENEW DELETE <DB> command is the preferred method of

re-creating the transaction database file, as it works even when
the database is too corrupt for the daemon to run. Note that <DB>
must be the transaction database for the current location, as the
command cannot be executed remotely.
When this command is used, ADMIN checks that all users have
left PDMS and that the daemon has been shut down. Note that
the check on the daemon takes up to 3 minutes. ADMIN then
deletes the file for the transaction database (not its DB entry) and
prompts the user to leave PDMS and restart the daemon. When
the daemon is restarted, it will automatically recreate the
transaction database file.
The RENEW <DB> AT <loc> command may be used to renew a

transaction database remotely. Note that this command may fail,
if the database corruption is severe and the daemon at <loc>
cannot be started. All users must be out of PDMS for the
command to run.
Alternatively, you may renew the transaction database by
stopping the daemon and deleting its file outside PDMS (not its
DB definition). The daemon will automatically create a new
transaction database file when it is restarted.
It is recommended that, after renewing, the System
Administrator should recover the transaction database at all
secondary locations. This will prevent reverse propagation.
For further information about reconfiguring or renewing a
transaction database, see Running Global Projects with
VANTAGE PDMS.
The RENEW command is not recorded in the transaction
database.

Version 11.5
Command Details
RENEW (continued)
Examples:
RENEW DELETE <db>
Renews the transaction DB at the current location
RENEW TRANSACTION/LON AT LON
Renews the transaction DB for London at location London
Command Syntax:
>--- RENEW ---+-- DELETE ----- dbname -----.

| |
`-- dbname --- AT <loc> -----+--- >
Related Commands: RECONFIGURE, RECOVER

Version 11.5
Command Details
REORDER (Global Project Administration)
Function: Reorders the members list of an element.
In a Global Project, this command is particularly useful for

Databases, as the list order at a location determines the order in
which Databases are propagated. For example, a Catalogue
database should be propagated before any Design Databases which
reference it.
Examples:
REORDER 2 BEFORE 1
Command Syntax:
>-- REORDer element_id ---+--- BEFore ---.

| |
‘--- AFTer ----+--- list_position --->

Version 11.5
Command Details
REPLICATE (Project definition)
Function: Saves the project in a file so it can be replicated.
Description: This command can be used:

• To replicate the complete Project, including all data (except
the ISO subdirectories), to a new project. You use the
REPLICATE command to do this.
• To replicate the structure of a standard (non-global)
project to file. You use the REPLICATE SYSTEM
command to do this.
• To replicate the structure of a global project to file:
Use REPLICATE SYSTEM to replicate the structure of the
project at the current location.
Use REPLICATE SYSTEM STANDALONE to replicate the
project as a standard project, omitting references to
Locations and communications.
Use REPLICATE SYSTEM SATELLITE at a Satellite in a
global project to replicate the project as represented in the
local System database. That is, the local information about
Users, MDBs and Communication Events will be stored, but
not the elements which can only be created and deleted at
the Hub.
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.
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 stages allocates databases to satellites and makes the
relevant databases primary at satellites.

Version 11.5
Command Details
REPLICATE (continued)
Before you run the macro to recreate the project structure, you
must create the new project-related directories. 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.
REPLICATE SYSTEM filename
Generate macro to replicate the project structure. If the current project
is global, the macro will include Location and Communication details.
REPLICATE SYSTEM /filename FILENUMBERS
Generate macro in a file /filename to replicate the complete data in the
current project, maintaining the same file numbers.
REPLICATE SYSTEM /filename OVERWRITE
Generate macro to replicate the complete data in the current project.
The data will be saved in the named file. If the file exists, it will be
overwritten.
REPLICATE SYSTEM STANDalone filename
Generate macro to replicate the project setup for a stand-alone (non-
global) project. This omits all references to Locations and
Communication elements.
REPLICATE SYSTEM SATELLite filename
Generate macro to replicate the project setup for a satellite of a
Global project. This outputs the commands for building the System
database only, not the Global database, that is, Teams, DBs and
Locations are omitted.

Version 11.5
Command Details
REPLICATE (continued)
Command Syntax for a Standard (non-global) project:
>-- REPLICATE -+- code ----------------------------.

| |
`- SYSTEM filename -+- FILENumbers -|
| |
`---------------+- OVERwrite -.
| |
‘-------------+-->
Command Syntax for a Global project:

>- REPLICATE -+- code -----------------------------------------------.
| |
`- SYSTEM -+- STANDalone -. |
| | |
|- SATELLite --+----------------------------|
| | |
`--------------+- filename -+- FILENumbers -|
| |
`---------------+- OVERwrite --.
| |
‘--------------+-->
The FILENumbers option maintains the same file numbers.

The OVERWRITE option overwrites an existing file of the same name.

Version 11.5
Command Details
RESETXREFS (Reconfiguration)
Function: Controls a partial update of references following a multi-database

reconfiguration.
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:
RESETXREFS WITH /REFFILE RESOLVE DB MASTER/DESNEW
where /REFFILE is the name of the file generated by the XREF
command and MASTER/DESNEW is the corresponding DB to be updated.
Command Syntax:
>-- RESETxrefs --+-- WIth --.

| |
‘----------+-- name --*-- RESOLve --+-- DB --.
| | |
| ‘--------+-- dbname --.
| |
‘-- END ----------------------------+-->
Related Commands: XREF, LOAD, RCFUPDATE DB

Version 11.5
Command Details
REVERT (Project administration)
Function: Allows you to restore a database to a previous session.
Description: This command is similar to the BACKTRACK command. Sessions

are defined as the work done between SAVEWORK commands.
You can revert to the date or session number required, or, if the
required session has been stamped, you can revert to the stamp.
The current state of the database will be lost.
Any elements which are claimed out to users or extracts must
exist in the backtracked session.
This command has a different effect from BACKTRACK. Instead
of truncating the database, a new session is added that is a copy
of the required session. This means that unlike BACKTRACK,
REVERT can always be reversed.
Examples:
REVERT PIPE/PIPE to 10:30
Reverts database to the session current at 10:30.
REVERT PIPE/PIPE to 31 MAY
Reverts database to the session current on 31st May.
REVERT PIPE/PIPE to SESS 10
Reverts database to the session 10.
REVERT PIPE/PIPE to STAMP /stamp_012
Reverts database PIPE/PIPE to the session that has the stamp
/stamp_012.
Command Syntax:
>-- REVERT dbname to <when> --->
Related Commands: BACKTRACK, MERGE CHANGES,

REMOTE REVERT (Global project only)

Version 11.5
Command Details
SAVEWORK (General PDMS Command)
Function: Updates the System database.
Description: Some commands automatically do a SAVEWORK command. These

are:
REPLICATE project
On Global projects:
ALLOCATE
DEALLOCATE
HUBLOCATION
CHANGE PRIMARY
PREVOWNER HUB
SYSTEMLOC
GENERATE LOCATION
ADMINISTER
CREATE EXTRACT
CREATE WORKING EXTRACT
MERGE CHANGES GLOBAL
Command Syntax:
>--- SAVEWORK --->
Related Commands: GETWORK, FINISH

Version 11.5
Command Details
SET (Project definition and Global Project Administraion)
Function: Sets the current administrative element.
Description: Set the specified MDB, DB Set or Team as the current one for the
addition or removal of DBs or users, respectively.
• Once a team has been set, DBs owned by that team can be
referred to by using the database part of the name only.
• ADD, DEFER, REMOVE, CURRENT and EXCHANGE
require an MDB to be set.
• Databases can only be added to a DB set once the DB Set
has been specified.
Examples:
SET MDB /RAB
Sets current MDB as RAB.
SET DBSET /ASET
Sets current DB Set as ASET.
SET TEAM PIPING
Sets current team as PIPING. Abbreviated references to the DBs
/AREA-A, /AREA-B etc. will automatically be taken as references to the
actual DBs PIPING/AREA-A, PIPING/AREA-B etc.
Command Syntax:
>--- SET ----+--- MDB name ------.

| |
|--- DBSET name ----|
| |
`--- TEAm name -----+--->
Querying:
>--- Query SET --+--- MDB ----.

| |
|--- DBSET --|
| |
`--- TEAM ---+--->
Related Commands: CREATE, ADD, DADD

Version 11.5
Command Details
STATISTICS (Data Integrity Checking)
Function: Produces a summary of information about the database being

checked.
command.
Description: STATISTICS ON causes DICE to produce a statistical summary of

the DB, including its size, the number of elements contained
within it, etc.
during the checking. This is the default setting.
Examples:
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
Command Syntax:
>--- STATistics ---+--- OFF ----.

| |
‘--- ON -----+--->
during the checking. This is the default.

Version 11.5
Command Details
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.
Project:
User: HVAC (75dws52)
Teams: HVAC
MDB: /HVAC
Command Syntax:
>--- STATUSSession -->
Related Commands: SYSTAT

Version 11.5
Command Details
STOP (Data Integrity Checking)
Function: Exits from DICE when it is running in stand-alone mode.

Examples:
STOP
Related Commands:
FINISH has the same effect
Command Syntax:
>--- STOP --->

Version 11.5
Command Details
SYNCHRONISE (Global Project Administration)
Function: Updates databases with the changes from another location.
Description: This command updates one or all databases at an on-line Location

with the changes in the corresponding databases at another
location.
By default, the updates will be taken from the Primary Location,
but the Hub Administrator can specify that they will be taken
from another Location which is an immediate neighbour of the
Location requiring the updates.
Unlike UPDATE, the transfer is one-way only: the synchronising
Location only receives updates, it does not send them. All
Locations in the communications network between the two
Locations being synchronised will also be updated.
Note that if the more up-to-date database has been compacted,
that is, sessions have been merged, or if it has been backtracked,
the entire database will be transferred.
Updates for offline Locations can only come from the Hub.
Examples of synchronisation of constructor databases:

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.
SYNCHRONISE STEELN/STEELN AT LON
Synchronise given database at location LON with its Primary location.
SYNCHRONISE ALL AT LON
Synchronise all databases at location LON with their Primary
locations.
SYNCHRONISE STEELN/STEELN WITH LON
Synchronise given database at current location with location LON.

Version 11.5
Command Details
SYNCHRONISE (continued)
SYNCHRONISE ALL WITH LON

Synchronise all databases at current location with location LON.
SYNCHRONISE STEELN/STEELN AT LON WITH CAM
Synchronise single database at location LON with location CAM.
Examples of synchronisation of system databases:

SYNCHRONISE SYSTEM WITH CAM
Synchronise the System Database for the current Location with
location CAM
SYNCHRONISE SYSTEM AT LON WITH CAM
Synchronise the System Database for the current location at location
LON with location CAM
SYNCHRONISE SYSTEM FOR OXF AT LON WITH CAM
Synchronise the System Database for OXF at location LON with
location CAM
Examples of synchronisation of the global database:

SYNCHRONISE GLOBAL WITH CAM
Synchronise the Global Database at the current Location with location
CAM
SYNCHRONISE GLOBAL AT LON WITH CAM
Synchronise the Global Database at location LON with location CAM
SYNCHRONISE GLOBAL AT OXF
Synchronise the Global Database at OXF with the current location
Command Syntax:
>- SYNCHronise -+- dbname --------------------.

| |
|- SYSTEM -+- FOR -+-- LOCAL -|
| | | |
| | `-- <loc> -|
| | |
| `------------------|
| |
|- GLOBAL --------------------|
| |
`- ALL -----------------------+- AT <loc> --.
| |
`-------------+- WITH <loc> -.
| |
`--------------+--->
Related Commands: UPDATE, RECOVER

Version 11.5
Command Details
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.
Examples: The following is an example of output:

PROJECT SAM
=============
User HVAC (75d-sg52)
Name au (A.User)
Host sg52
Entered 14:37 10 Sep
Module DESIGN
MDB /HVAC
DB MODE
HVAC/DESI RW
HVAC/PADD R
HVAC/COMP R
HVAC/CATA R
MASTER/PIPECATA R
MASTER/STLCATA R
MASTER/HVACCATA R
MASTER/SUPPCATA R
MASTER/PADD R
MASTER/DICT R
MASTER/PROP R
User HANGER (3c41-sg107)
Name an (A.N. Other)
Host sg107
Entered 14:39 10 Sep
Module DRAFT
MDB /HANGERS

Version 11.5
Command Details
SYSTAT (continued)
DB MODE
HANGERS/DESI R
HANGERS/PADD RW
HANGERS/CATA R
MASTER/PIPECATA R
MASTER/STLCATA R
MASTER/HVACCATA R
MASTER/SUPPCATA R
MASTER/PADD R
MASTER/DICT R
MASTER/PROP R
2 user(s) listed
This shows 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.
In a Global project, there may also be a SYSTEM user running

the Globaldaemon module. This shows that the daemon is
running.
You can restrict the output to information about the user, host,
module or MDB as shown in the following examples:
SYS USER HVAC
Lists the information for the user HVAC
SYS NAME an
Lists the information for the user id an
SYS HOST ’sg107’
Lists the information for the workstation sg107
SYS MODULE DRAFT
Lists the information for any users of DRAFT
SYS MDB HVAC
Lists the information for any users of the MDB HVAC

Version 11.5
Command Details
SYSTAT (continued)
Command Syntax:
>--- SYStat ---+----------------------.
| |
|--- USER username ----|
| |
|--- NAME ’loginid’ ---|
| |
|--- HOST ’hostid’ ----|
| |
|--- MODUle module ----|
| |
‘--- MDB name ---------+--->

Version 11.5
Command Details
SYSTEMLOCATION (Global Project Administration - Hub Only)
Function: Changes the Administering Location of a Satellite.
Description: The SYSTEMLOC command changes the primary location of the

System database for the specified location. The primary location
of the Hub system database cannot be changed: the Hub cannot
be administered remotely.
• The SYSTEMLOC command cannot complete while there are
users in PDMS with write access to the system database. The
command will eventually complete once all such users have left
PDMS. You may need to use EXPUNGE to remove phantom
users.
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
PREVOWN SYSTEM AT locname
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:
SYSTEMLOCation LON PRIMARY AT OXF
Changes the Primary Location of the Location LON to be the Location
OXF, so that LON can be administered from OXF.
SYSTEMLOCation OXF LOCAL
Changes the Primary Location of the Location LON to be at LON, so
that LON can be administered locally.
SYSTEMLOCation OXF HUB
Changes the Primary Location of the Location OXF to be the Hub.

Version 11.5
Command Details
SYSTEMLOCATION (continued)
Command Syntax:
>-- SYSTEMLOCation <loc> --+-- PRIMARY AT <loc> --.

| |
|-- LOCAL -------------|
| |
`-- HUB ---------------+-->
Related Commands: ADMINISTER, PREVOWNER SYSTEM
Querying: >--- Q PRMLOC --->

At a Location, shows the Primary Location for the Location.
>--- Q PRVRF --->

At a Location, shows the previous primary location until the
SYSTEMLOC command has completed. This attribute is normally
unset.

Version 11.5
Command Details
TADD (Project definition)
Function: Adds users to the Set (i.e. Current) team.
Examples:
TADD SJC
Add user SJC to the current Team.
Command Syntax:
.------<-----.
/ |
>--- TADD userid ---*--- userid ---’
|
‘----------------->
Related Commands: TREMOVE, SET

Version 11.5
Command Details
TERM (General PDMS Command)
Function: Terminates Alpha file.
Examples:
TERM
Terminates alpha file and outputs reports to screen. This syntax is
equivalent to ALPHA FILE END
Command Syntax:
>--- TERM ----->
Related Commands: ALPHA

Version 11.5
Command Details
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 location’s own transaction
database (using TO DB), the daemon must first be stopped.
Examples:
TO DB USERA/DESIGN
Reconfigured data to go to database USERA/DESIGN in current
project.
TO NEW USERM/DESIGN DBNO 777
Reconfigured data to go to new database USERM/DESIGN, number
777, in current project.
TO NEW USERM/DRAFT ACCESS UPDATE
Reconfigured data to go to new database USERM/DRAFT, N readers, 1
writer access rights, in current project.
TO DBFILE des008
Reconfigured data to go to specified file (assumes project directory is
current directory).
TO FILES /TEMP1 /TEMP2
Only pass 1 of reconfiguration to be carried out; partially reconfigured
data to be stored in named files.

Version 11.5
Command Details
TO (continued)
Command Syntax:
>- To -+- DBFile filename ---------------------------------------------------.

| |
|- DB dbname ---------------------------------------------------------|
| |
|- FIles ----------. |
| | |
|- BINaryfiles ----| |
| | |
|- FORMattedfiles -+- name name --------------------------------------|
| |
‘- NEW dbname -----+- IN AREA n -. |
| | |
‘-------------+- ACCess -+- UPDAte -----. |
| | | |
| |- CONTROL ----| |
| | | |
| ‘- MULTIWRITE -| |
| | |
‘-------------------------+- DBNO n -|
| |
‘----------+->
Related Commands: FROM, RCFCOPY

Version 11.5
Command Details
TRANSFER (Global Project Administration)
Function: Generate a directory containing copies of all database files at the

current location, including inter-db macro files, for transfer
between the Hub and an offline Location.
Description: This command is used at the Hub and at an offline location. All
the databases at the current location will be transferred. Before
the command is given, the environment variable pointing 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: ABC_SYD
At 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.

Version 11.5
Command Details
TRANSFER (continued)
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.
TRANSFER FROM loc
Updates the current location with the files transferred from Location
loc. Only databases that are allocated at the current location will be
read in.
Related Commands: GENERATE LOCATION
Command Syntax:
>--- TRANSFer ---+--- TO pathname <loc> ---.

| |
`--- FROM pathname -------+--->

Version 11.5
Command Details
TREMOVE (Project definition)
Function: Removes users from the Set (i.e. Current) team.
Examples:
TREM SJC
Removes user SJC from the current Team.
Command Syntax:
.-----<------.
/ |
>--- TREmove userid ---*--- userid ---’
|
‘-------------------->
Related Commands: TADD, SET

Version 11.5
Command Details
UNLOCK (Project administration)
Function: Unlocks all locked databases.
Note: Locking and Unlocking commands are not recorded in the

Examples:
UNLOCK
Unlocks all locked databases
In a Global Project, the System Administrator at the Hub or at a

Satellite’s administering location can unlock a Project at the
Satellite:
UNLOCK AT LON
Unlocks all locked databases at Location LON.
Command Syntax:
>--- UNLOck ---+---------------.

| |
‘--- AT <loc> --+-->
Related Commands: LOCK
Querying a Standard (non-global) Project:
>--- Query LOCK ----->
Querying a Global Project:
>--- Query LOCK ---+--------------.

| |
‘--- AT <loc> -+-->

Version 11.5
Command Details
UPDATE (Global Project Administration)
Function: Updates the current location and an immediate neighbour.
Description: This is a two-way process, unlike SYNCHRONISE. Databases at

the current location and databases at a neighbouring Location
will be updated, according to which Location has the most up-to-
date version.
Inter-db connection macros will also be transferred, and any
update script will be run. Update scripts are linked with Update
events by setting the EXECA and EXECA attributes of the
LCOMD element. See Section 4.2.2, Structure of the Global
Database.
Files such as Isodraft files, external plot files and Design manager
files are not propagated automatically by the global daemon.
However, there is a mechanism in 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
Management User Guide.
Both Locations must be on-line.
Examples of updating constructor databases:

UPDATE ALL WITH LON
All databases at the current location and all databases at Location
LON will be compared, and updated so that all have the most recent
data.
UPDATE PIPES/PIPES WITH CAM
The PIPES/PIPES database at the current location will be compared
with the PIPES/PIPES database at Location CAM. Updates will
transferred from the most up-to-date database to the other.

Version 11.5
Command Details
UPDATE (continued)
Examples of updating system databases:

UPDATE SYSTEM WITH CAM
The System database for the current location, at the current location,
will be compared with the System database for the current Location at
Location CAM. Updates will be transferred from the most up-to-date
database to the other.
UPDATE SYSTEM FOR OXF WITH CAM
The System database for location OXF at the current Location will be
compared with the System database for location OXF at Location CAM.
Updates will be transferred from the most up-to-date database to the
other.
Examples of updating the global database:

UPDATE GLOBAL WITH CAM
The Global database at the current location will be compared with the
Global database at Location CAM. Updates will be transferred from
the most up-to-date database to the other.
Command Syntax:
>--- UPDATE ---+--- dbname ---.

| |
|--- SYSTEM ---|
| |
|--- ALL ------|
| |
`--- GLOBAL ---+--- WITH <loc> --->
Related Commands: SYNCHRONISE

Version 11.5
Command Details
UPGRADE (Reconfiguration)
Function: Produces macros to upgrade a project to a new version of PDMS.
Examples:
UPGRADE /OUTMACRO /INMACRO
This will produce two macro files, OUTMACRO and INMACRO.
OUTMACRO will be used in the old PDMS version to dump the
contents of all DBs in the project to intermediate files. INMACRO will
be used in the new PDMS version to load the intermediate files and
recreate the complete project.
UPGRADE /OUTMACRO /INMACRO FOREIGN db1 db2 ...
All databases, including the list of foreign databases specified by the
FOREIGN option will upgraded.
UPGRADE /OUTMACRO /INMACRO FOREIGN ALL
All databases, including all foreign databases will upgraded.
Command Syntax:
.---<------.
/ |
>--- UPGrade macro1 macro2 ---+-- FOReign --*-- dbname --’
| |
‘-------------+--- ALL -----.
| |
`-------------+--->

Version 11.5
Command Details
VB (Reconfiguration)
Function: Gives very brief output for pass 2 reconfiguration.
Examples: A short example of very brief output is shown below. Compare

with the brief output shown in the BRIEF command.
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

Command Syntax:
>--- VB --->
Related Commands: BRIEF, FULL, ERRORS

Version 11.5
Command Details
XREF (Reconfiguration)
Function: Generates a list of the reference numbers of all elements which

need updating for each database prior to a multi-database
reconfiguration. Can be used when upgrading a project from one
version of PDMS to the next.
Support Office before using it.
Examples:
XREF /REFFILE
Reference number list to be written to file /REFFILE.
Command Syntax:
>--- XRef filename --->
Related Commands: RESETXREFS, DUMP, UPDATE DB

Version 11.5
Index
Attributes System Database (standalone projects), 4-1
non-reference Transaction Database, 5-1
handling of during reconfiguration, Destination database
3-1, 3-3 for reconfigure operations, 3-1, 3-3
reference DICE
handling of during reconfiguration, Exiting, 2-1
3-1, 3-3
Reports, 2-2
Binary-format files, 3-21
Setup Options, 2-2
BRIEF command, 3-8
Starting up, 2-1
Brief output mode, 3-8
User Message File, 2-1
Character-format files, 3-21
DUMP command, 3-12
Commands
Elements
Detailed Descriptions, 7-4
ACR (Access Control Rights), 4-9
Reconfiguration, 3-2
ACRL (ACR List), 4-9
Summary in Functional Groups, 6-1
ACRST (ACR Group), 4-9
Syntax Graphs, 7-1, 7-3
DB (Database), 4-4, 4-17
Communications elements
DBALL (Location DB List), 4-21
LCOMC (Admin Daemon Config), 4-13
DBL (Database List), 4-6
LCOMD (Comms Link Details), 4-13
DBLI (Database List), 4-4, 4-17
LCOML (LCOMD Elements List), 4-13
DBLOC (DB Location), 4-18
LCTIMD (Event Timings), 4-15
DBSET (DB Set), 4-6
LCTIML (Event Timer), 4-14
DBSTL (Database Set List), 4-6
LEVENL (Time Interval), 4-14
EXTLI (Extract List), 4-5
Copies of databases, 3-9
FNTF (Font), 4-3
Copy list (for reconfiguration), 3-3, 3-4, 3-13
GRP (Group), 4-19
DAtaBAse CONtrol program (DABACON),
3-1 GRPLI (Group List), 4-19
Database Description Languages (DDLs), 3-1 LNK (Links), 4-21
Database Structure LNKLI (Link List), 4-21
Elements and their Attributes, 4-1, 5-1 LOC (Location), 4-20
Global Database, 4-10, 4-15 LOCLI (Location List), 4-20
Local System Database, 4-12 MDB (MDB), 4-6
PEROP (Perops), 4-7, 4-18
VANTAGE PDMS ADMIN 1

Version 11.5
Command Details
ROLE (Role), 4-7, 4-18 treatment of when reconfiguring, 3-14

RUNF (Runfile or Module), 4-3 PDMS Data Integrity Checker (DICE), 2-1
SCOPE (Scope), 4-8 Picture files
STAMP (Stamp), 4-8, 4-22 treatment of when reconfiguring, 3-14
STLST (Stamp List), 4-8, 4-22 Plot files, 4-14, 7-160
TEAM (Team), 4-4, 4-17 Programmable Macro Language (PML), 1-1
TMLI (Team List), 4-5 Projects
USER (User), 4-5 transferring data between, 3-14
USLI (User List), 4-5 upgrading, 3-15
Errors RCFCOPY command, 3-4
reconfiguration RCFUPDATE command, 3-11, 3-12
controlling limit of for output, 3-9 Reconfiguration, 3-5
ERRORS command, 3-9 Extracts, 3-22
FROM command, 3-3, 3-14, 3-21 Global Projects, 3-22
FULL command, 3-8 same references, 3-6
Full output mode, 3-8 Transaction Database, 3-26
Global Commands, 1-1 RECONFIGURE command, 3-5
Groups RECONFIGURER, 3-1
reconfiguring, 3-14 Reference attributes, 3-10, 3-12
INCLUDE command, 3-13 Reference number index, 3-11
Index loading from file, 3-12
of reference numbers, 3-11 saving to file, 3-12
Intermediate files, 3-1, 3-3 Reference Number Index
Isodraft files, 4-14, 7-160 listing, 3-6, 3-7
LOAD command, 3-12 References
Manual Content, 1-1, 1-2 between databases, 3-10
Messages, 3-18 Relevant User Guides, 1-1
New version of PDMS REPLICATE command, 1-1
transferring data to, 3-1 RESETXREFS command, 3-15
Offline location, 4-14, 4-20, 6-3, 7-12, 7-22, 7- Root element, 3-13
23, 7-37, 7-48, 7-66, 7-74, 7-75, 7-80, 7- SAMEREF option, 3-6
104, 7-108, 7-145, 7-150, 7-156
Source database
Output
for reconfigure operation, 3-1, 3-3
controlling, 3-8
TO command, 3-4, 3-14, 3-21
PADD databases
2 VANTAGE PDMS ADMIN

Version 11.5
Command Details
Transaction elements World, 4-7

TRDAY (Command Date Day), 5-3 World elements
TRFAIL (Transaction Failure), 5-12 ACRW (Access Control Rights), 4-8
TRFLST (Transaction Failure List), 5-11 DBSTWL (DB Set), 4-6
TRINCO (Transaction Incoming FTWL (Font), 4-3
Command), 5-4
GLOCWL (Global Location), 4-19
TRLOC (Transaction Location), 5-3
GROWL (Global Role), 4-18
TRMESS (Transaction Message), 5-12
GSTAT (Global Status), 4-16
TRMLST (Transaction Messages List), 5-11
GSTWLD (Global Stamp), 4-21
TRMONT (Command Date Month), 5-3
GTMWL (Global Team), 4-16
TROPER (Transaction Operation), 5-10
LCOMW (Communications), 4-12
TROUCO (Transaction Output Command),
MDBW (MDB), 4-5
5-7
RFWL (Runfile or Module), 4-3
TRSLST (Transaction Success List), 5-11
ROWL (Role), 4-6
TRSUCC (Transaction Success), 5-12
STAT (Project Status), 4-3, 4-12
TRUSER (Transaction User), 5-3
STWLD (Stamp), 4-8
TRYEAR (Command Date Year), 5-3
TMWL (Team), 4-4
Transferring data
TRMSGW (Transaction Message), 5-3
to a new version of PDMS, 3-1
USWL (User), 4-5
Upgrade macros, 3-16
XREF command, 3-15
VB Command, 3-8
Very Brief output mode, 3-8
VANTAGE PDMS ADMIN 3

Version 11.5

Pdms Admin: Command Reference Manual

Uploaded by

Copyright:

Available Formats

Pdms Admin: Command Reference Manual

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pdms Admin: Command Reference Manual

Uploaded by

Copyright:

Available Formats

PDMS ADMIN

Command Reference Manual

 Copyright 1991 through 2003 AVEVA Solutions Limited

Date Version Notes

Section 7 PREVOWNER updated to cover built-in recovery

Section 7 RENEW updated to cover DELETE option

VANTAGE PDMS ADMIN

VANTAGE PDMS ADMIN Contents-i

3.19 Reconfiguring Extracts ............................................................................................ 3-22

Contents-ii VANTAGE PDMS ADMINlt

ALPHA (General PDMS Command) ......................................................................7-15

VANTAGE PDMS ADMIN Contents -iii

MODULE (Module Definition) ............................................................................... 7-96

Contents-iv VANTAGE PDMS ADMINlt

VANTAGE PDMS ADMIN 1-1

1.2 How to Use This Manual

1-2 VANTAGE PDMS ADMIN

2.1 DICE Errors

VANTAGE PDMS ADMIN 2-1

2.2 DICE Commands

2-2 VANTAGE PDMS ADMIN

3.1 The Reconfiguration Process

Reconfiguration is a two-pass operation, acting on either a complete database or on

VANTAGE PDMS ADMIN 3-1

3.2 Starting up RECONFIGURER

Enter PDMS in non-graphics (tty) mode by typing:

3.3 Administrative and Querying Commands

3-2 VANTAGE PDMS ADMIN

3.4 Basic Reconfiguration

3.4.1 Reconfiguring a Single Database

3.4.2 Specifying the Source Database

VANTAGE PDMS ADMIN 3-3

FROM PROJECT XXX STEELS/STEEL

FROM DBFILE /abc016

3.4.3 Specifying the Destination DB

TO NEW HVAC/HVAC DBNO 777

3.4.4 Specifying What Will be Copied

3-4 VANTAGE PDMS ADMIN

3.4.5 Starting the Reconfiguration Process

3.4.6 Example of a Simple Reconfiguration

VANTAGE PDMS ADMIN 3-5

*** Pass one initiated ***

EC SITE #32/202 =42/205

*** Pass two completed ***

3.5 Using the SAMEREF Option

When a DB is reconfigured, the reference numbers of the elements in the destination DB

FROM FILE /F1/F2

3.6 Using the SESSIONS Option

3-6 VANTAGE PDMS ADMIN

3.7 Listing the Reference Number Index

VANTAGE PDMS ADMIN 3-7

3.8 Global Projects

3.9 Controlling RECONFIGURER Output

3-8 VANTAGE PDMS ADMIN

If the specified limit is reached, reconfiguration is abandoned and the DB is left

3.10 Copies and Reconfigured Copies of DBs

PIPEA/PIPEA DESI NUMBER 2 FILENAME /%DRA000%/dra001 UPDATE

ADMIN/TEST DESI NUMBER 2 FILENAME /%DRA000%/dra003 UPDATE

USER/DRAFT PADD NUMBER 5 FILENAME /%DRA000%/dra004 UPDATE

* Pass one initiated *

* Pass two completed *

/S /T /U /M /DS /RO /SC /ST /*ACR