ADMIN Command Reference Manual PDF

PDMS11.
6SP3/Admin Command Reference Manual

Issue 300406

PDMS Admin
Admin Command Reference Manual
Version 11.6SP3

AVEVA Solutions Limited, High Cross, Madingley Road, Cambridge, CB3 0HB, UK
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
and which may not be licensed to you. For further information on which Products are licensed
to you please refer to your licence conditions.
! Copyright 1991through 2006 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

VANTAGE PDMS ADMIN Revision History-i
Command Reference Manual
Version 11.6SP3
Revision History
Date Version Notes
March 2003 11.5
Miscellaneous updates for this release.
Sept 2004 11.60
Miscellaneous updates for this release.
June 2005 11.6.SP1
Updates and minor corrections.
April 2006 11.6.SP3
Updates for Global 2.4.

VANTAGE PDMS ADMIN contents-i
Version 11.6SP3
Contents
1 Introduction ................................................................................................... 1-1
1.1 Macros ........................................................................................................................... 1-1
1.2 How to Use This Manual ............................................................................................... 1-1
2 Stand-Alone DICE.......................................................................................... 2-1
2.1 DICE Errors ................................................................................................................... 2-1
2.2 DICE Commands........................................................................................................... 2-1
3 Reconfiguration............................................................................................. 3-1
3.1 The Reconfiguration Process........................................................................................ 3-1
3.2 Starting up RECONFIGURER....................................................................................... 3-1
3.3 Administrative and Querying Commands ..................................................................... 3-2
3.4 Basic Reconfiguration.................................................................................................... 3-2
3.4.1 Reconfiguring a Single Database................................................................. 3-2
3.4.2 Specifying the Source Database .................................................................. 3-3
3.4.3 Specifying the Destination DB...................................................................... 3-3
3.4.4 Specifying What Will be Copied ................................................................... 3-4
3.4.5 Starting the Reconfiguration Process........................................................... 3-4
3.4.6 Example of a Simple Reconfiguration .......................................................... 3-5
3.5 Using the SAMEREF Option ......................................................................................... 3-5
3.6 Using the SESSIONS Option ........................................................................................ 3-6
3.7 Listing the Reference Number Index ............................................................................ 3-6
3.8 Global Projects .............................................................................................................. 3-7
3.9 Controlling RECONFIGURER Output ........................................................................... 3-7
3.10 Copies and Reconfigured Copies of DBs ..................................................................... 3-8
3.10.1 Copies............................................................................................. 3-8
3.10.2 Reconfigured Copies .................................................................................... 3-9
3.11 Advanced Reconfiguration ............................................................................................ 3-9
3.11.1 References Between Databases.................................................................. 3-9
3.11.2 Updating References into a Reconfigured Database................................. 3-10
3.11.3 Saving the Reference Number Index ......................................................... 3-11
3.11.4 Copying Parts of Databases....................................................................... 3-11
3.11.5 Copying Groups .......................................................................................... 3-13
3.12 Transferring Data Between Projects ........................................................................... 3-13
3.13 Upgrading a Project ..................................................................................................... 3-14
3.14 Reconfiguration Messages.......................................................................................... 3-17
3.14.1 Standard Information Messages................................................................. 3-18
3.14.2 General Format of Pass 2 Error Messages................................................ 3-18
3.14.3 Codes Used to Identify Message Types..................................................... 3-19
3.15 Database Transfers between Computers ................................................................... 3-19
3.16 Binary and Character Files.......................................................................................... 3-20
3.17 The Transfer Process.................................................................................................. 3-20
3.18 Reconfiguring a Global Project ................................................................................... 3-20
3.19 Reconfiguring Extracts ................................................................................................ 3-21
3.19.1 Outputting Changes Only ........................................................................... 3-21
3.19.2 The SAMEREF Option................................................................................ 3-21
3.19.3 The SESSIONS Option............................................................................... 3-21
Contents
VANTAGE PDMS ADMIN contents-ii
Version 11.6SP3
3.19.4 Reconfiguring a Single Extract ................................................................... 3-22
3.19.5 Reconfiguring a Family of Extracts............................................................. 3-22
3.19.6 The RCFUPDATE command...................................................................... 3-23
3.19.7 Example of Reconfiguring a Three Level Extract....................................... 3-23
3.19.8 Reconfiguring the Transaction Database in a Global Project .................... 3-25
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-6
5.7 TROPER element (Operation) ...................................................................................... 5-9
5.8 TRMLST, TRSLST, and TRFLST elements................................................................ 5-11
5.9 TRMESS, TRSUCC, and TRFAIL elements............................................................... 5-11
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-3
6.8 Data Integrity Checking ................................................................................................. 6-3
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-2
7.3 Detailed Descriptions of Commands............................................................................. 7-3
ACCESS (Project definition) ................................................................................................ 7-4
ACRADD (Project definition)................................................................................................ 7-5
ACRREM (Project definition) ............................................................................................... 7-6
ADD (Project definition) ....................................................................................................... 7-7
ADMINISTER (Global Project Administration - Remote Administration) .............................. 7-8
ALLOCATE (Global Project Administration - Hub only) ...................................................... 7-11
ALPHA (General PDMS Command).................................................................................... 7-14
BACKTRACK (Project Administration) ................................................................................ 7-15
BRIEF (Reconfiguration)...................................................................................................... 7-17
CANCELCOMMAND (Global Project Administration)......................................................... 7-18
CDESC (Project definition) .................................................................................................. 7-19
CHANGE (Project definition) ............................................................................................... 7-20
CHECK (Data Integrity Checking) ....................................................................................... 7-24
CHECKOPTION (Data Integrity Checking) ......................................................................... 7-27
CNAME (Project definition).................................................................................................. 7-31
COPY (Project definition)..................................................................................................... 7-33
Contents
VANTAGE PDMS ADMIN contents-iii
Version 11.6SP3
CREATE (Project definition) ................................................................................................ 7-35
CURRENT (Project definition) ............................................................................................. 7-42
DADD (Project definition)................................................................................................... 7-43
DEALLOCATE (Global Project Administration - Hub only) ................................................. 7-44
DEFER (Project definition)................................................................................................... 7-46
DELETE (Project definition)................................................................................................. 7-47
DREMOVE (Project definition) ............................................................................................ 7-50
DUMP (Reconfiguration)...................................................................................................... 7-51
DUPLICATENAMES (Global Project Administration) ......................................................... 7-52
EDIT (Module definition) ...................................................................................................... 7-54
ERRORFILE (Data Integrity Checking) ............................................................................... 7-56
ERRORS (Reconfiguration)................................................................................................. 7-57
EXCHANGE (Project definition) .......................................................................................... 7-58
EXCLUDE (Project definition).............................................................................................. 7-59
EXPUNGE (Project administration) ..................................................................................... 7-60
EXTERNAL (Data Integrity Checking)................................................................................. 7-62
EXTRACT (Project administration)...................................................................................... 7-64
FINISH (General PDMS Command).................................................................................... 7-67
FONTDIRECTORY (Font definition) ................................................................................. 7-68
FONTFAMILY (Font definition) ............................................................................................ 7-69
FROM (Reconfiguration)...................................................................................................... 7-71
FULL (Reconfiguration)........................................................................................................ 7-72
GENERATE (Global Project Administration - Hub only) ..................................................... 7-73
GETWORK (General PDMS Command)............................................................................. 7-75
HUBLOCATION (Global Project Administration - Hub only)............................................... 7-76
INCLUDE (Project definition) ............................................................................................... 7-78
INITIALISE (Global Project Administration)......................................................................... 7-79
ISOLATION (Global Project Administration) ....................................................................... 7-80
LIST (Querying).................................................................................................................... 7-81
LOAD (Reconfiguration) ...................................................................................................... 7-84
LOCK (Project administration) ............................................................................................. 7-85
MAKE GLOBAL (Global Project Administration)................................................................. 7-86
MAXERRORS (Data Integrity Checking) ............................................................................ 7-87
MAXUSERS (Project Administration) .................................................................................. 7-88
MAXWARNINGS (Data Integrity Checking) ........................................................................ 7-89
MERGE CHANGES (Project Administration) ...................................................................... 7-90
MESSAGE (Project administration)..................................................................................... 7-93
MODE (Data Integrity Checking) ......................................................................................... 7-94
MODULE (Module Definition) .............................................................................................. 7-95
MOVE (Project administration) ............................................................................................ 7-97
NEW (Project definition and Global Project Administration) ............................................... 7-98
NEW STAMP (Project administration)............................................................................... 7-100
PING (Global Project Administration) ................................................................................ 7-102
PREVOWNER (Global Project Administration - Hub only) ............................................... 7-103
PROJECT (Project definition) ............................................................................................ 7-105
PURGE (Project Administration and Global Project Administration) ................................ 7-107
QUERY (Querying) ............................................................................................................ 7-108
RCFCOPY (Reconfiguration)............................................................................................. 7-113
RCFUPDATE (Reconfiguration) ........................................................................................ 7-114
RCFUPGRADE (Reconfiguration)..................................................................................... 7-115
RECONFIGURE (Reconfiguration) ................................................................................... 7-116
RECOVER (Global Project Administration)....................................................................... 7-118
REINIT (Reconfiguration) .................................................................................................. 7-121
REMOTE (Global Project Administration) ......................................................................... 7-122
REMOTEMESSAGE (Global Project Administration) ....................................................... 7-128
Contents
VANTAGE PDMS ADMIN contents-iv
Version 11.6SP3
REMOVE (Project definition) ............................................................................................. 7-129
RENEW (Global Project Administration) ........................................................................... 7-130
REORDER (Global Project Administration)....................................................................... 7-132
REPAIR (Global Project Administration) ........................................................................... 7-133
REPLICATE (Project definition)......................................................................................... 7-134
RESETXREFS (Reconfiguration) ...................................................................................... 7-137
REVERT (Project administration) ...................................................................................... 7-138
SAVEWORK (General PDMS Command) ........................................................................ 7-139
SET (Project definition and Global Project Administration) .............................................. 7-140
SORTALLOCATE ............................................................................................................... 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 ................................................................................................................. index-i

VANTAGE PDMS ADMIN 1-1
Version 11.6SP3
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.
1.2 How to Use This Manual
Chapter 2 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
Introduction
Version 11.6SP3
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.

Version 11.6SP3
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.
2.2 DICE Commands
Set up the options you require using the following commands (see the appropriate command
pages for details):
ERRORFILE
MODE
MAXERRORS
Stand-Alone DICE
Version 11.6SP3
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.6SP3
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.
3.2 Starting up RECONFIGURER
Enter PDMS in non-graphics (tty) mode by typing:
pdms tty
Reconfiguration
Version 11.6SP3
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.
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.
Reconfiguration
Version 11.6SP3
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
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
Reconfiguration
Version 11.6SP3
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 are to be reconfigured into an existing DB,
identified by its name or that of the file containing it. The destination DB must be of the same
type as the source DB, and will normally be empty, but need be. For an explanation of what
happens when the DB is not empty, see 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.
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:
Reconfiguration
Version 11.6SP3
" 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:
*** 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.
Reconfiguration
Version 11.6SP3
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, 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, or GLOBAL 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.
Reconfiguration
Version 11.6SP3
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
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 Satellites 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.
Reconfiguration
Version 11.6SP3
In FULL mode, all information output in BRIEF mode is given, plus a log of all elements
successfully created and named. Note that FULL mode is very verbose and its use is not
generally recommended.
The default is BRIEF mode.
An upper limit may be set on the number of errors that are acceptable during Pass 2 of a
reconfiguration using the ERRORS command. For example:
ERRORS 50
If the specified limit is reached, reconfiguration is abandoned and the DB is left unaltered.
By default, RECONFIGURER allows an unlimited number of errors to occur. This situation
may be reset if necessary by using the ERRORS command followed by a negative value. For
example:
ERRORS -1
3.10 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.
Reconfiguration
Version 11.6SP3
3.10.2 Reconfigured Copies
A reconfigured copy is one named by the TO DB or TO NEW commands. The key features of
reconfigured copies are:
" A reconfigured copy has a different DB number from that of the source DB.
" 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:
DESIGN DB 1
DESIGN DB 2
Branch /150-B1
Nozz /E1-N2
CREF /150-B1
HREF /E1-N2

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.
Reconfiguration
Version 11.6SP3
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 DB MASTER/DESIGN INTERNAL
Updates references in DB MASTER/DESIGN for any elements that have been copied
with RCFCOPY ALLCONNECTIONS. Use this option with care because it is possible to
update a reference that has already been changed by the RECONFIGURE command.
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
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
Reconfiguration
Version 11.6SP3
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.
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
Reconfiguration
Version 11.6SP3
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.
3.11.4.1 Setting External References
In cases where you have made a partial copy of a database, sometimes it is necessary for you
to ensure the external references are correct in the copied elements.
For example, if you moved a piping zone to a different database while maintaining the
references to an equipment zone which was to remain it the original database, the copied
piping zone could have unset external references and the equipment zone would remain
connected to the original piping zone.
In these cases you can use the ALLCONnections option to set the external references for the
reconfigurered elements:
RCFCOPY /SITE1 INTO /SITE2 ALLCONNECTIONS
Reconfiguration
Version 11.6SP3
This will set all references including those within the original database not in the list of copied
elements.
To update the references of the original database to point to the new copied elements use the
RCFUPDATE INTERNAL command described in Section 3.11.2.
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:
Reconfiguration
Version 11.6SP3
In the source project:
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.
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
Reconfiguration
Version 11.6SP3
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
Write Input phase
$R6
Checkddl is 11
To db STANA/SAPROP
From files /REC1A /REC1B
Xref /REC1X
Reconfigure
To db DEREKF/DFPROP
Xref /REC2X
Reconfiguration
Version 11.6SP3
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
Copy all
Reconfigure
From db TAMH/THPROP
Copy all
Reconfigure
From db TAMH/PROP_ATEST
Copy all
Reconfigure
Reconfiguration
Version 11.6SP3
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.
Reconfiguration
Version 11.6SP3
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).
Reconfiguration
Version 11.6SP3
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.
Reconfiguration
Version 11.6SP3
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
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.
Reconfiguration
Version 11.6SP3
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 The 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.
Reconfiguration
Version 11.6SP3
3.19.4 Reconfiguring a Single Extract
The procedure for reconfiguring a single leaf extract is as follows:
5. Reconfigure from the DB to a file.
6. REVERT the extract to Session 1.
7. MERGE CHANGES to remove the intermediate session.
8. 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:
Reconfiguration
Version 11.6SP3
9. Refresh TEAMA/EXTRACT.
10. Reconfigure TEAMA/MASTER to file /A, /B.
11. Reconfigure TEAMA/EXTRACT to file /C, /D.
12. REVERT TEAMA/EXTRACT to Session 1.
13. MERGE CHANGES on TEAMA/EXTRACT.
14. REVERT TEAMA/MASTER to Session 2.
15. MERGE CHANGES on TEAMA/MASTER.
16. Reconfigure from file /A, /B to TEAMA/MASTER.
17. Refresh TEAMA/EXTRACT (to pick up changes made in Step 8).
18. 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:

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.)
MASTER
MASTER
EXT
EXTBOT
Reconfiguration
Version 11.6SP3
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.
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)
Reconfiguration
Version 11.6SP3
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.6SP3
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.
The System and Global Databases
Version 11.6SP3

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.
RUNF
Modules
Runfile information: you can
only modify these elements
using the MODULE and
EDIT commands
/*
WORLD
World
FTWL
Font
World
FNTF
Font
Files
/*M
MDBW
MDB World
MDB
MDBs
DB
DBs
DBL
DB List
/*DS
DBSTWL
DB Set
World
DBSET
DB Sets
/*RO
ROWL
Role
World
ROLE
Roles
PEROP
Perops
/*SC
SCOW
Scope
World
SCOPE
Scopes
/*ACR
ACRW
ACR
World
ACR
ACRs
ACRST
ACR
Groups
ACRL
ACR Lists
/*ST
STWLD
Stamp
World
STAMP
Stamps
STLST
Stamp List
/*T
TMWL
Team World
TEAM
Teams
DBLI
DB
Lists
USLI
User
Lists
DB
DBs
USER
Users
/*U
USWL
User World
TMLI
Team
Lists
EXTLI
Extract
Lists
DB
DBs
DBSTL
RFWL
Module
World
/*S
STAT
Status World
Version 11.6SP3
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
Hccnt Extract list changes count Integer =< 999999

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%/
Version 11.6SP3
The Font File Element (FNTF)
Attributes
Name /name
Lock false
Owner /name
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
Version 11.6SP3
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

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
Version 11.6SP3
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 /*
The MDB Element (MDB)
Attributes
Name /name
Lock false
Owner /*M
Curdbs List 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
Version 11.6SP3
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)
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
Version 11.6SP3
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 /*
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
Version 11.6SP3
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 /*
The ACR Element (ACR)
Attributes
Name /name
Lock false
Owner /*ACR
Roleref Nulref 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.6SP3
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.6SP3

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)
Runfile information: you can
only modify these elements
using the MODULE and EDIT
commands
RUNF
Modules
DB
DBs
/*
WORLD
World
/*S
STAT
Status World
/*T
TMWL
Team
World
(empty)
/*DS
DBSTWL
DB Set
World
RFWL
Modules
World
FTWL
Fonts
World
FNTF
Font
Families
/*M
MDBW
MDB World
MDB
MDBs
DB
DBs
/*SC
SCOW
Scope
World
/*ACR
ACRW
ACR
World
DBSET
DB Sets
DBL
DB List
SCOPE
Scopes
ACR
ACRs
/*RO
ROWL
Role
World
(empty)
ACRST
ACR Sets
ACRL
ACR Lists
/*LC
LCOMW
Comms
World
LCTIML
Event
Timer
LCOMC
Daemon
config
USER
Users
/*U
USWL
User World
TMLI
Team
Lists
EXTLI
Extract
Lists
LCOML
Comms
Links
List
LCTIMD
Timings
DBSTL LCOMD
Scheduled
Updates
Version 11.6SP3
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.6SP3
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)
Execa unset 120 character text: name of script to be run after updates are
transferred (optional)
LNoUpd false If set TRUE, the scheduled update is disabled. This is useful
during certain house-keeping operations such as merging.
Version 11.6SP3
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 external plot files files are not propagated automatically by the global
daemon. However, there is a mechanism in the daemon to allow such files to be transferred to
and from neighbouring locations, during scheduled updates (or the UPDATE ALL command).
The directory to receive transferred files is defined by the environment variable %IMPORT%.
Each location to which files are to be transferred requires its own transfer directory -
%EXP_ABC% for location ABC. Transfer of other data is described more fully in the Global
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.
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
Version 11.6SP3
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.6SP3
WORLD
World
/*GS
GSTAT
Global Status
World
LOCLI
Location
List
LNKLI
Links List
GRP
Groups
LNK
Links
LOC
Locations
/*GL
GLOCWL
Location World
/*GRO
GROLW
Global
Role World
ROLE
Roles
/*GST
GSTWLD
Global
Stamp
World
STAMP
Stamps
STLST
Stamp
List
GRPLI
Group List
/*GT
GTMWL
Global
Team World
TEAM
Teams
DB
DBs
DBLI
DB List
DBLOC
PEROP
Perops

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:
" 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.
Version 11.6SP3
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 DB element owns the list element DBLOC which holds four additional attributes (see
DBLOC element, page 4-18). These attributes are attached to the DBLOC element to facilitate
separate claiming of both this element and the owning DB element. This scheme reduces the
contention between the PDMS ADMIN module and the Plant Design Global daemon.
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
Variant false
Controlled false
Version 11.6SP3
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
Condition unset
Acrmessage unset
Version 11.6SP3
GLOCWL Element
The Global Location World element GLOCWL specifies information about Locations, Groups
and Communications (Links). It is named /*GL and only one /*GL element can exist in the
database. The GLOCWL element consists of the three list elements GRPLI for groups, LOCLI
for locations and LNKLI for links. It has the following attributes:
Attributes
Name /*GL
Lock false
Owner /*
Aduuid text Daemon version string (Project UUID)
Hubrf /name Hub Location Reference
Prvrf Nulref Previous Hub Reference (normally unset)
NxtHb Nulref Next Hub location (normally unset)
Newuid text gets new UUID value to use when setting ADUUID.
To be used when a Global project is copied directly
without the REPLICATE command (see page 7-134)
having been used.
GRPLI Element
The GRPLI element contains a list of Group elements GRP. A Group is a fully connected local
network of Locations which conceptually form a single node in the Plant Design Globaltree
structure of Locations.
Attributes
Name /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.6SP3
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
CURLOC True current Location (available everywhere)
ADMLOC Currently administered location
(available everywhere)
Version 11.6SP3
DBPRIMARY (ref array) - List of Databases primary at the current
location
LOCPRIMARY (ref array) - List of Locations primary at the current
location
NoExtCreation default false If true, disables the creation of extracts by this
location. Extract creation must be done by the Hub (or an authorised
administering location)
LCpOvWrite default false If true, database files which are locked by dead
users may be overwritten if an update requires an entire file copy.
Note: When a Global Project is created an initial Location element is created
with a NAME of /PROJECTHUB and a LOCID of HUB. Its LINIT flag is
set to TRUE.
Note: Do not allow locked files in the current project to be overwritten during
copying by Global updates if other projects are using the current project
as a foreign one. This is because database readers in the other projects
are valid users even though they are not recorded as users in the current
project.
DBALL Element
Attributes
Lock 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.
Version 11.6SP3
Attributes
Name /*GST
Lock false
Owner /*
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.6SP3
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 owners names.
The structure is a hierarchy leading to input commands received by the daemon, and the
operations these have evaluated to.
The Transaction Database
Version 11.6SP3
%TRMSG
%TRYEAR
%TRMONT
%TRDAY
%TRINCO
%TROPER %TROUCO
%TRFLST %TRMLST
%TRMESS
%TRUSER
%TRLOC
%TRFAIL
%TRSLST
%TRSUCC
%TRSUCC %TRFAIL

Figure 5-1 Structure of the Transaction Database.

Version 11.6SP3
5.2 TRMSGW element
The Transaction Message World element is called /*MS. There is only one such element and it
contains elements that store the communication between the daemon, PDMS and other
daemons. It owns any number of TRYEAR elements.
Attributes
NAME Text /*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.6SP3
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 CLAIMetc
/2002/MAR/25/REMOTEDAEMON ../OXF CLAIMetc
../LON CLAIMetc
../HOU CLAIMetc
/2002/MAR/25/TIMEDUPDATES ../CAM UPDATE ALLetc
/2002/MAR/25/SYSTEM ../CAM CLAIMetc
/2002/MAR/25/FRED ../CAM CLAIMetc
/2002/MAR/25/ROSE ../CAM CLAIMetc
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 locations 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
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.
Version 11.6SP3
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 dependent,
(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
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.6SP3
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.
5.6 TROUCO element (Output Command)
The TROUCO element contains 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.
Version 11.6SP3
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
dependent.
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.
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.
Version 11.6SP3
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).
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.
Version 11.6SP3
REPLIED A reply with results has 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.
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 dependent.
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.
Version 11.6SP3
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.
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.
Version 11.6SP3
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.
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 claimed
element)
" A double integer code relating to a PDMS message or error (0,0 if not known or
relevant)
" A text string which is a representation of the said message or error.
" An integer qualifier to be used for such things as session numbers etc.
The result of a command (TROUCO) is the sum of all TRSUCC and TRFAIL elements owned
by its operations and output commands. All of these are communicated back to either the user
(if it is a local command) or propagated to the originating site (if it is a foreign command). In
the latter case the compounded errors will appear under the relevant originating TROUCO
operation and hence onwards and upwards.
Whether a TROPER itself is classed as a success is determined by its execute method. Input
Commands are successes if all its operations AND output commands are successes. An output
Version 11.6SP3
Command is a success if the input command it spawned returns a success. Results are only
passed on to the generating TROUCO when the input command is totally finished.
Messages are sent immediately they are generated before waiting for operation or command
conclusion. They go the same route as the result, being compounded by a TROUCO and
transmitted to other site TROPER elements. They are only stored under the final TRINCO
generated from a USER command.
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).
TRTYPE text Pseudo-attribute, which combines the OPTYPE
(Operation Number) and COMMTYPE (Command
Number) attributes.
Allows you to query the member operations of a
command independently of whether the operations
are TROUCO or TROPER. It combines the TRCNUM
and TRONUM queries (these are attributes of
TROUCO and TROPER respectively).

Version 11.6SP3
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).
TRTYPE text Pseudo-attribute, which combines the OPTYPE
(Operation Number) and COMMTYPE (Command
Number) attributes.

Version 11.6SP3
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.
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.
Command Summary
Version 11.6SP3
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.
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.
Command Summary
Version 11.6SP3
SET Sets the current MDB, Team, or DB Set.
SORTALLOCATE Sorts an allocation list so that Database extracts are in the correct
hierarchical order
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.
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.
Command Summary
Version 11.6SP3
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).
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.6SP3
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:
>----+--- ABC -----.
| |
|--- PQR -----|
| |
-------------+--->
" means you can type in ABC or PQR or just press Enter to get the default option.
Command Details
Version 11.6SP3
" Text in angle brackets <. . . > is the name of another syntax graph. This
convention is used for syntax which occurs in many places. The graphs referred
to are described at the end of this section. For example:
>----+--- ABC -----.
| |
|--- PQR -----|
| |
|--- <dia> ---|
| |
-------------+--->
" means you can type in ABC or PQR or any command allowed by the syntax
given in diagram <dia> or just press Enter to get the default option.
" Points marked with an asterisk (*) are loop back junctions. Command options
following these may be repeated as required. For example:
.-----<-------.
/ |
>---*--- option1 ---|
| |
|--- option2 ---|
| |
--- option3 ---+--->
" means that you can enter any combination of option1 and/or option2 and/or
option3, where the options can be commands, other syntax diagrams, or
command arguments.
" The simplified format:
.----<------.
/ |
>---*--- name ----+--->
" means that you may type in a list of PDMS names, separated by at least one
space.
7.2 Notes on Syntax Graphs
<loc>
When a Location needs to be specified, it is shown as <loc> in the syntax 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
Command Details
Version 11.6SP3
<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
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.
Command Details
Version 11.6SP3
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

Command Details
Version 11.6SP3
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 ---'
|
`--------------------->

Command Details
Version 11.6SP3
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 ---'
|
`--------------------->

Command Details
Version 11.6SP3
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

Command Details
Version 11.6SP3
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.
Command Details
Version 11.6SP3
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
locations 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 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.
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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 Locations
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.
Command Details
Version 11.6SP3
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.

Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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

Command Details
Version 11.6SP3
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.
The backtracked database is written to a new file. This is done to avoid
the situation where secondary database files in a Global project could
still contain removed sessions. This situation would cause propagation
failures if further sessions were added to the backtracked file.
Note: For extracts, the REVERT command is used instead of
BACKTRACK.
Examples:
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.
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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
attribute given

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

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

Command Details
Version 11.6SP3
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

Command Details
Version 11.6SP3
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

Command Details
Version 11.6SP3
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.
Command Details
Version 11.6SP3
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.
Command Details
Version 11.6SP3
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.
Command Details
Version 11.6SP3
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)
Command Details
Version 11.6SP3
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 0,
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.
Notes: Remote checking uses stand-alone DICE.
When a DICE report indicates that buckets have been lost,
normally this would require the master database to be patched.
However in a global project, this error is non-fatal if there are
working extracts. These databases are non-propagating and
only exist at the primary location of their extract owner. This
results in the error report, since the buckets for working
extracts are not accessible at the primary location of the master
db.
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 projects System DB. In a Global Project, the
current administered System DB is checked.
CHECK COMMDB
Checks the integrity of the projects Comms DB.
CHECK MISCDB
Checks the integrity of the projects Misc DB.
CHECK GLOBALDB
Checks the integrity of the projects Global DB.
Command Details
Version 11.6SP3
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 ------------------------------------------------+-->
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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 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.
Command Details
Version 11.6SP3
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.
Command Details
Version 11.6SP3
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:
Command Details
Version 11.6SP3
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:
>--- CHECKOption ----+- EXTernal --+- CHECK -+-----------------------.
| | | |
| | `- PREFerence -+- NONE -|
| | | |
| | `- mdb --|
| | |
| |-- NOCHeck ----------------------|
| | |
| `-- REject -----------------------|
| |
|- MOde -------+-- FUll ------------------------|
| | |
| `-- BRief -----------------------|
| |
|- STATistics -+-- FULL ------------------------|
| | |
| |-- ON --------------------------|
| | |
| `-- OFF -------------------------|
| |
|- MAXErrors n ---------------------------------|
| |
|- MAXWarnings n -------------------------------|
| |
|- CLAIM ------+-- ON --------------------------|
| | |
| `-- OFF -------------------------|
| |
`- PATCh ------+-- ON --------------------------|
| |
`-- OFF -------------------------+-->
Related Commands: CHECK
Command Details
Version 11.6SP3
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 users 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 TEAMNAME/GBPADD TEAMNAME/GBDRAFT
Change DB GBPADD to GBDRAFT if GBDRAFT does not exist.
CN DB TEAMNAME/GBPADD TEAMNAME/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.
Command Details
Version 11.6SP3
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

Command Details
Version 11.6SP3
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 teams 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.
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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.
Command Details
Version 11.6SP3
CREATE (continued)
In a Global Project, you can only create Teams and Master Databases
at the Hub. Extracts can be created at any authorised location. Working
Extracts can only be created at locations where the owning extract
database is Primary.
Offline Locations: Working extracts cannot be created at an offline
location that is administered by the Hub. The offline location must be
locally administered.
Authorised locations: A location is authorised to create extracts (for
itself or an administered location) if its NOEXTC attribute is false. The
Project hub is always authorised to create extracts.
Examples:
Creating Teams, Users and MDBs
CR TEAM PIPING
Create Team PIPING
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.
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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 -.
| |
|- DESI -|
| |
|- ISOD -|
| |
|- PROP -|
| |
|- PADD -|
| |
- DICT -+- IN AREA n -.
| |
-------------+---> cont

cont >--- ACCess -+- UPDATE -----.
| |
+- CONTRolled -.
| |
`- MULTIWrite -+- CLAIM -+- EXPLicit -|
| |
`- IMPLicit -+-----------+-->
cont
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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.
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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.
Occasionally it is necessary to perform routine housekeeping and other
maintenance on satellite databases and then it is advantageous to be
able to deallocate them temporarily. To do this we can use the
KEEPMDBS option. When the database is reallocated, it becomes
available once more after the MDB is reselected.
Warning: When a user at a satellite accesses an MDB which contains a
de-allocated database it will be treated as a deferred database. This
may lead to unexpected errors since attributes in other databases may
still contain references to this database.
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.
Command Details
Version 11.6SP3
DEALLOCATE PIPE/PIPE KEEPMDBS AT CAM
Temporarily deallocates and makes unavailable for use database PIPE/PIPE,
which exists at Location CAM.
Command Syntax:
>- DEALLOC/ATE --- ALL ---+--- KEEPMDB/S --.
| |
`----------------+--- AT --- loc --->

>- DEALLOC/ATE - teamid - dbname -+- KEEPMDB/S -.
| |
`------------+- AT - loc -+-INC/LUDING - DESCEND/ANTS->
|
`------>
The KEEPMDBS option means that the database will not be removed from MDBs at the
satellite although its database file will be deleted and the database removed from the
location's allocation list. This option is useful when a database is being de-allocated
temporarily for housekeeping procedures. A replacement database with the same details will
be available for use immediately it is re-allocated without any need to modify MDBs.
SORTAL/LOCATE --- loc --->
This command sorts extract databases in a location's list of allocated databases into master-
child-grandchild order, so that extract owners precede extract children. Note that this
command will have no effect until the relevant databases have been allocated.
Related Commands: ALLOCATE, CHANGE
Querying: At a location:
>--- Q DBALL
At a Database:
>--- Q DBLC --->

Command Details
Version 11.6SP3
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

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

Command Details
Version 11.6SP3
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.
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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 --->
Command Details
Version 11.6SP3
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 entrys 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.

Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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

Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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.
Note: EXPUNGING users re moves them from the COMMS
database but does not end their PDMS session or remove the file-
locks on the database. To remove these locks you can use the
Microsoft NETFILE API or proprietary tools like pstools from
Sysinternals.
Alternatively you can set the LCPOVW attribute to TRUE, which
allows the damon to overwrite locked files provided there are no
database READERS (as recorded in the Session data in the
COMMS database).
Warning: do not use this facility if the project has users from
other projects. Such users are valid database READERS but are
not recorded in the Session data for the current project
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.

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

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

Command Details
Version 11.6SP3
FINISH (General PDMS Command)
Function: The FINISH command saves work and leaves PDMS.
Examples:
FINISH
Command Syntax:
>--- FINISH --->
Related Commands: SAVEWORK
Command Details
Version 11.6SP3
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 users current directory.
Examples:
FONTD /%PDMSEXE%
Command Syntax:
>--- FONTDirectory name --->
Querying: >--- Q FONTDirectory --->
Related Commands: FONTFAMILY, Q FONTS
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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 --->
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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
Locations 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.
Command Details
Version 11.6SP3
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 --->
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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 previous Primary location using the
command:
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.
Command Details
Version 11.6SP3
HUB LOCATION (continued)
Command Syntax:
>--- HUBLOCation <loc> ---+-----------------.
| |
`--- AT <time> ---+--->
Related Commands: PREVOWNER HUB, ALLOCATE ALL
Querying: >--- Q HUBRF --->
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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> ---.
| |
`----------------+--->

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

Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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 transaction
database.

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> ---.
| |
`-----------------+--->
Command Details
Version 11.6SP3
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 --->
Command Details
Version 11.6SP3
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 --->
Command Details
Version 11.6SP3
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 --->
Command Details
Version 11.6SP3
MAXWARNINGS (Data Integrity Checking)
Function: Specifies the maximum number of warnings found before data integrity
checking is abandoned.
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 --->
Command Details
Version 11.6SP3
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.
Command Details
Version 11.6SP3
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>

Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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)
Command Details
Version 11.6SP3
MODE (Data Integrity Checking)
Function: Specifies what happens when DICE finds an error.
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.
Command Details
Version 11.6SP3
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. The default value is 2560000 but the Administrator may specify
a larger or smaller value than this. Note that the buffer size should be
at least this value in projects where distributed Extracts are being used.

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> -->
where the <runf> keywords are defined as follows:
Command Details
Version 11.6SP3
.--------------------------.
/ |
>--- 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 --+--->
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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.
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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 ------------------------------------+--->
Command Details
Version 11.6SP3
NEW STAMP (continued)
Related Commands: BACKTRACK, MERGE CHANGES, REVERT
Querying: >--- Query attribute --->
where the current element is a stamp.

Command Details
Version 11.6SP3
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> --->
Note: This command is now also available in other modules, such as DESIGN and
DRAFT
Related Commands: Q COMMS
Command Details
Version 11.6SP3
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 locations own transaction
database
" If the CREATE EXTRACT command fails before it has reached its
Allocate Primary command.
Note: PREVOWNER is not usually needed after a failure of this
command since it contains an in-built recovery operation. However,
the automatic recovery operation does not cover the CREATE
command Allocate operation and PREVOWNER may be needed in
the unlikely event of this failing.
In all other circumstances it is better to await the completion of the in-
built recovery operation, since this prevents incompatible changes being
made by two competing users at different locations.
Note: This command cannot be used to reverse a successful CHANGE
PRIMARY, HUBLOCATION or SYSTEMLOCATION
command.
Command Details
Version 11.6SP3
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.
Command Details
Version 11.6SP3
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

Command Details
Version 11.6SP3
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 ------+-->
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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 HCCNTAt a DB element, gives the extract list changes count. This value increases
when extracts are inserted or removed.
Note: The superseded ELCCNT pseudo-attribute is retained as a
synonym for HCCNT. HCCNT is available at /*S and /*GS elements as
well as at DB elements.
Q CLCCNT
At a DB element, gives the claim list changes count. This value increases
when elements are claimed or dropped without other changes to the
database.
Note: In a Global project, the above three attributes together with session
information can be used to compare the state of the database at different
locations. For information about this, see Running Global Projects with
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.
Command Details
Version 11.6SP3
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 project lock at location LON.
Q PROJ LOCK AT LON
Returns the project lock at location LON
Q REMOTE LON SAMPLE/DESI FILEDETAILS
Returns details of the latest session number, compaction number and other
file details for the database at the specified location. These details are used
by the Global daemon when sending a database update, and can be useful
when analysing the progress of scheduled updates.
Q REMOTE LON SAMPLE/DESI LASTSESSION
Returns Session information for the last session of the specified database at
the specified location. The output is equivalent to that from Q SESSION
SAMPLE/DESI at the current location. Note that it is not possible to query
sessions other than the latest at a remote location.
Note: Q COMMS, Q ISOLAT and Q PROJ LOCK are now available in other
modules such as DESIGN
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.

Command Details
Version 11.6SP3
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 ----------------+--->
Command Details
Version 11.6SP3
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 --.
| |
`-----------+-->
For details of Q REMOTE, see under REMOTE
Related Commands: LIST, Q REMOTE
Command Details
Version 11.6SP3
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.
RCFCOPY <SITEA> INTO <SITEB> ALLCONNECTIONS
Sets all references, including those in the original database that are not in
the list of copied elements.
Command Syntax:
.-------------<-----------------.
/ |
>- RCFCopy ---*- ALL ------------. |
| | |
|- CATalogue ------| |
| | |
|- SPECifications -| |
| | |
|- name -----------| |
| | |
`- refno ----------+--- AND ------|
| |
|--- comma ---
|
`--- INto -+- name --+-ALLCONnections -.
| | |
- refno -+-----------------+->
Querying: Q COPIES
Related Commands: FROM, TO, RECONFIG
Command Details
Version 11.6SP3
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 DB MASTER/DESIGN INTERNAL
Updates references in DB MASTER/DESIGN for any elements that have
been copied with RCFCOPY. Use this option with care because it is possible
to update a reference that has already been changed by the RECONFIGURE
command.
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 -+--------------.
| `-- INTERNAL --|
| |
|--- MDB mdbname --------------|
| ---------|
|--- TEam teamname ------------|
| |
|--- ALL ----------------------|
| |
------------------------------+-->
Related Commands: RECONFIGURE
Command Details
Version 11.6SP3
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 ---+-->

Command Details
Version 11.6SP3
RECONFIGURE (Reconfiguration)
Function: Starts a reconfiguration operation. You can specify that the reference
numbers stay the same in the reconfigured database. You can specify
that session information such as the original session comment, session
number, username and original date stays the same in the reconfigured
database.
Description: You can specify that the reference numbers stay the same in the
reconfigured database. The SAMEREF option will fail if:
" The database specified in the TO DB command has a different DB
number from the database given in the FROM DB command.
" An element already exists with the same reference number.
You can specify that session information stays the same in the
reconfigured database by using the SESSIONS option:
" The option is not valid for SYSTEM, or GLOBAL DBs.
" The option is not available if you are doing a partial
reconfiguration. You must use the RCFCOPY ALL command with
RECONFIG SESSIONS.
" For extracts, RECONFIG SESSIONS will be assumed, even if the
option is not given.
" For Draft DBs, the picture files will be ignored.
" The reconfigured data must go TO a file.
" After reconfiguration, data can be read back in from the file,
replacing the original DB data. The SAMEREF option is assumed
when reading the data.
" When reading in data created by RECONFIG SESSIONS, the DB
number and extract number must be the same as the originating
DB number and extract number.
" If errors occur when reading in data created by RECONFIG
SESSIONS, the data is not saved unless you use the RECONFIG
FORCE option.
The normal procedure for reconfiguring a database and maintaining the
reference numbers is as follows:
1. Reconfigure from the target database to a file.
2. Delete the target database, and create a new one with the same DB
number.
Command Details
Version 11.6SP3
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 0, 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)
Command Details
Version 11.6SP3
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.

Command Details
Version 11.6SP3
RECOVER (continued)
Examples: The examples are based on the following configuration:

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
AAA
BBB
CCC
DDD
EEE
This is the Hub
You are here
You are
administering
DDD from CCC
STEELN/STEEL
N is Primary at
EEE
PIPEN/PIPEN
is Primary at
CCC
Command Details
Version 11.6SP3
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> --.
| |
`----------------+--->
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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.
At Global 2.4 you can perform Queries on the REMOTE function to
allow reporting on session details and other file details for remote
satellites.
The REMOTE . . . BACKTRACK, REVERT, MERGE CHANGES and
EXPUNGE commands can be given at the Hub, the Satellite itself or
the administering location. The Satellite itself may need to use the
REMOTE version of the command, because it may not have write access
to the system database. The administering Location may need to use
the REMOTE version of the command, because it may not have write
access to the constructor database.
The REMOTE . . . CHECK command can be given at any location.
Certain REMOTE commands cannot be used for Extract databases see
below.
Note: The difference between the REMOTE options, and centralised
administration of a satellite, are that REMOTE commands are
executed by the Global Daemon, rather than by PDMS. All
daemon commands take time to complete, and generally you
will need to wait for this to happen.
" The REMOTE commands (other than CHECK) can only be applied
to databases which do not own extracts and to leaf extracts.
" REMOTE . . . BACKTRACK, MERGE CHANGES and EXPUNGE
commands will not take effect while there are users (or potential
users, for example, in MONITOR) in the project.
" REMOTE . . . BACKTRACK will do nothing if the primary location
of the database contains later sessions than the secondary database
at the issuing location. It will not backtrack through stamped
sessions. The database must be allocated at the issuing location in
order to determine the latest session there.
Command Details
Version 11.6SP3
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). REMOTEMERGE will not remove Stamped
sessions. Unless the database is non-propagating, it must be
allocated at the issuing location in order to determine the latest
session there.
REMOTE MERGE also merges the database at secondary locations
after it has been merged at the primary location in order to prevent
unnecessary copying of the entire database when it is next updated.
This means that the command may take some time to complete.
You are advised to stop scheduled updates and avoid adhoc updates
until the entire REMOTEMERGE command has completed. If
scheduled updates are left in place, then unnecessary copying of
entire databases will be undertaken, and changes made by users at
the primary location may be lost.
" The REMOTE . . . CHECK command can be given at any location
on any database. Both Primary and Secondary databases can be
checked. This command runs stand-alone DICE on the specified
database from the daemon at the specified location and reports back
to the location that issued the command.
However, extract databases cannot usefully be checked in isolation
(using CHECK FILE), since access to the extract owner is required.
This means that REMOTE CHECK cannot be used on Extract
databases other than the extract master.
" You can also query information about the project status at a
Satellite. See Querying below.
" REMOTEEXPUNGE cannot distinguish between genuine and
dead users of a database at a location. The system administrator
should use remote session information (see Querying below) to
check which users are actually writing to the database.
" REMOTEMERGE and REMOTEBACKTRACK are not valid for
extracts which own other extracts. However, REMOTEREVERT
and REMOTEEXPUNGE can be used. A database that owns
extracts can be merged in PDMS using the MERGE command.
Command Details
Version 11.6SP3
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.
Command Details
Version 11.6SP3
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> -+-->
| |
`--------------+-->

Command Details
Version 11.6SP3
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

Command Details
Version 11.6SP3
REMOTE (continued)
Querying:
Remote database session information can be queried using the Q
REMOTE command:
Q REMOTE <loc> <dbname> FILEDETAILS
Q REMOTE <loc> <dbname> LASTSESSION
The success of database updates may be monitored using
these queries.
Where <dbname> can be one of:
GLOBAL
SYSTEM
SYSTEM FOR LOCAL
SYSTEM FOR <loc>
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()
q var !r[1].user()
q var !r[1].mdb().
This may be combined with information about the satellite MDBs to
identify users of a database when using REMOTEEXPUNGE.
For more information about PML Objects see the Plant Design Software
Customisation Reference Manual. Only these three session methods are
available for remote sessions.
Returns data about a given
session
Command Details
Version 11.6SP3
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 --->
Command Details
Version 11.6SP3
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

Command Details
Version 11.6SP3
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 available 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.
Command Details
Version 11.6SP3
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

Command Details
Version 11.6SP3
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 --->
Command Details
Version 11.6SP3
REPAIR (Global Project Administration)
Function: Repairs the System database, to remove deleted global elements
including deleted databases.
NOTE: you will not be prompted to carry out a Repair as a result of
the system finding de-allocated databases. This results from using
DEALLOCATE with the KEEPMDBS option
In a Global Project, this command may be used to Repair or Check
Repair needed to the System database. There are four main commands:-
Q REPAIRrequired Returns an integer indicating the number of
illegal entries in the System database.
REPAIR outputs a report and Repairs the database.
REPAIR NOCHECK Repairs the database without a report.
REPAIR CHECKONLY Outputs a report without Repairing the
database.
The latter is useful when using ADMIN in READONLY mode, as at a
satellite with a secondary system database.
Examples:
Q REPAIRREQUIRED
REPAIR
REPAIR CHECKONLY
REPAIR NOCHECK

Command Syntax:
>-- REPAIR ---+-----------------.
| |
+--- NOcheck -----+
| |
----CHECKonly----+----->
Related Commands: DEALLOCATE

Command Details
Version 11.6SP3
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 stage allocates databases to satellites and makes the
relevant databases primary at satellites.
Command Details
Version 11.6SP3
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. In a Global project, a new UUID value for the Project is
set (stored in ADUUID of /*GL; this is because each project requires a unique
value of this attribute. This is used by Global daemons to distinguish
between projects at the same location).
Notes: A new UUID value may be queried at /*GL using Q NEWUID.
The administrator may use this value to set ADUUID manually if
a Global project has been copied externally to PDMS.
If ADUUID is left unchanged, there may be data corruption since
daemons may send data to the wrong project.
The ADUUID attribute is essential to distinguish between Global
projects. Each project should have a unique value of ADUUID. This
value is what the Global daemon uses to select the correct project.
For example if the user copies a project using the file system,
rather than by using the REPLICATE command, then the ADUUID
attribute in both projects will be the same, and this may cause
commands from one Global project to be received by the wrong
Global project.
It is therefore essential that the PDMS Administrator resets the
ADUUID attribute of the project. The NEWUID attribute provides
a way to get a new value, since it makes a 'uuidgen' query. The
Administrator can then use the result of the NEWUID attribute
query to set the ADUUID attribute. Note that NEWUID is not an
attribute of the database. It is a pseudo- attribute provided for the
purpose of generating a new uid value for ADUUID.

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.
Command Details
Version 11.6SP3
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. Outputs the commands for building the System database only, not
the Global database, that is, Teams, DBs and Locations are omitted.
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.
Command Details
Version 11.6SP3
RESETXREFS (Reconfiguration)
Function: Controls a partial update of references following a multi-database
reconfiguration.
advised to consult your AVEVA Solutions Support Engineer
before using it.
Description: Updates the cross-references listed in a file created by the XREF
command. Can be used when upgrading a project from one version of
PDMS to the next.
Examples:
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

Command Details
Version 11.6SP3
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)

Command Details
Version 11.6SP3
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

Command Details
Version 11.6SP3
SET (Project definition and Global Project
Administration)
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
Command Details
Version 11.6SP3
SORTALLOCATE
Function: Re-orders database extracts in a database allocation list
Description: Re-orders database extracts in a locations allocation list into the correct
extract order, so that extract children follow the parent extract. This
affects the order in which database updates are sent.
NOTE: This command does not sort the order of unrelated
databases. It is up to the system administrator to ensure a
sensible order.
Examples:
Command Syntax: SORTALLOCATE loc
Querying: Q DBALL to query an allocation list.
Related Commands: ALLOCATE, DEALLOCATE, Q DBALL

Command Details
Version 11.6SP3
STATISTICS (Data Integrity Checking)
Function: Produces a summary of information about the database being checked.
Description: STATISTICS ON causes DICE to produce a statistical summary of the
DB, including its size, the number of elements contained within it, etc.
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 -----+--->
the checking. This is the default.
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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 --->

Command Details
Version 11.6SP3
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.
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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/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
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
SYSTAT (continued)
Command Syntax:
>--- SYStat ---+----------------------.
| |
|--- USER username ----|
| |
|--- NAME loginid ---|
| |
|--- HOST hostid ----|
| |
|--- MODUle module ----|
| |
--- MDB name ---------+--->
Command Details
Version 11.6SP3
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 previous Primary
location using the command:
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.
Command Details
Version 11.6SP3
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.

Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
TO (Reconfiguration)
Function: Specifies the destination database for reconfiguration.
In a Global Project, the TO NEW option can only be used at the Hub.
The TO DB option can only be used at the Primary Location of a
database. When reconfiguring the locations own transaction database
(using TO DB), the daemon must first be stopped.
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.
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
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.
Command Details
Version 11.6SP3
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 -------+--->
Command Details
Version 11.6SP3
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
Command Details
Version 11.6SP3
UNLOCK (Project administration)
Function: Unlocks all locked databases.
Note: Locking and Unlocking commands are not recorded in the transaction
database.
Examples:
UNLOCK
Unlocks all locked databases
In a Global Project, the System Administrator at the Hub or at a
Satellites administering location can unlock a Project at the Satellite:
UNLOCK AT LON
Unlocks all locked databases at Location LON.
Command Syntax:
>--- UNLOck ---+---------------.
| |
--- AT <loc> --+-->
Related Commands: LOCK
Querying a Standard (non-global) Project:
>--- Query LOCK ----->
Querying a Global Project:
>--- Query LOCK ---+--------------.
| |
--- AT <loc> -+-->

Command Details
Version 11.6SP3
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 and external plot 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.
Updates of individual databases obey network routing. The database
will be synchronised with the database at locations on the route to the
primary location; and updated with the database on the route from the
primary location to the destination.
Both Locations (and any intermediate locations) must be on-line.
Examples of updating constructor databases:
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 be transferred from
the most up-to-date database to the other.
UPDATE DIRECT PIPES/PIPES WITH CAM
Direct update of PIPES/PIPES database at the current location with CAM,
ignoring any intermediate locations.
NOTE: This command should be used with caution, since it may result in
Reverse propagation errors at intermediate locations,
Command Details
Version 11.6SP3
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

Command Details
Version 11.6SP3
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 be upgraded.
UPGRADE /OUTMACRO /INMACRO FOREIGN ALL
All databases, including all foreign databases will upgraded.
Command Syntax:
.---<------.
/ |
>--- UPGrade macro1 macro2 ---+-- FOReign --*-- dbname --
| |
-------------+--- ALL -----.
| |
`-------------+--->

Command Details
Version 11.6SP3
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

Command Details
Version 11.6SP3
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.
advised to consult your AVEVA Solutions 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

VANTAGE PDMS ADMIN index-i
Version 11.6SP3
Index
Attributes
non-reference
handling of during reconfiguration, 3-1,
3-3
reference
handling of during reconfiguration, 3-1,
3-3
Binary-format files, 3-20
BRIEF command, 3-7
Brief output mode, 3-7
Character-format files, 3-20
Commands
Detailed Descriptions, 7-3
Reconfiguration, 3-2
Summary in Functional Groups, 6-1
Syntax Graphs, 7-1, 7-2
Communications elements
LCOMC (Admin Daemon Config), 4-13
LCOMD (Comms Link Details), 4-13
LCOML (LCOMD Elements List), 4-13
LCTIMD (Event Timings), 4-15
LCTIML (Event Timer), 4-14
LEVENL (Time Interval), 4-14
Copies of databases, 3-8
Copy list (for reconfiguration), 3-2, 3-4, 3-11
DAtaBAse CONtrol program (DABACON), 3-1
Database Description Languages (DDLs), 3-1
Database Structure
Elements and their Attributes, 4-1, 5-1
Global Database, 4-10, 4-15
Local System Database, 4-12
System Database (standalone projects), 4-1
Transaction Database, 5-1
Destination database
for reconfigure operations, 3-1, 3-2
DICE
Exiting, 2-1
Reports, 2-2
Setup Options, 2-1
Starting up, 2-1
User Message File, 2-1
DUMP command, 3-11
Elements
ACR (Access Control Rights), 4-9
ACRL (ACR List), 4-9
ACRST (ACR Group), 4-9
DB (Database), 4-5, 4-17
DBALL (Location DB List), 4-21
DBL (Database List), 4-7
DBLI (Database List), 4-4, 4-17
DBLOC (DB Location), 4-18
DBSET (DB Set), 4-6
DBSTL (Database Set List), 4-7
EXTLI (Extract List), 4-6
FNTF (Font), 4-4
GRP (Group), 4-19
GRPLI (Group List), 4-19
LNK (Links), 4-21
LNKLI (Link List), 4-21
LOC (Location), 4-20
LOCLI (Location List), 4-20
MDB (MDB), 4-6
PEROP (Perops), 4-7, 4-18
ROLE (Role), 4-7, 4-18
RUNF (Runfile or Module), 4-3
SCOPE (Scope), 4-8
STAMP (Stamp), 4-8, 4-22
STLST (Stamp List), 4-9, 4-22
TEAM (Team), 4-4, 4-17
TMLI (Team List), 4-6
Index
VANTAGE PDMS ADMIN index-ii
Version 11.6SP3
USER (User), 4-5
USLI (User List), 4-5
Errors
reconfiguration
controlling limit of for output, 3-8
ERRORS command, 3-8
FROM command, 3-3, 3-13, 3-20
FULL command, 3-7
Full output mode, 3-7
Global Commands, 1-1
Groups
reconfiguring, 3-13
INCLUDE command, 3-12
Index
of reference numbers, 3-10
Intermediate files, 3-1, 3-3
Isodraft files, 4-14, 7-160
LOAD command, 3-11
Manual Content, 1-1
Messages, 3-17
New version of PDMS
transferring data to, 3-1
Offline location, 4-14, 4-20, 6-2, 7-11, 7-21, 7-22,
7-36, 7-47, 7-65, 7-73, 7-74, 7-79, 7-103, 7-
107, 7-145, 7-150, 7-156
Output
controlling, 3-7
PADD databases
treatment of when reconfiguring, 3-12
PDMS Data Integrity Checker (DICE), 2-1
Picture files
treatment of when reconfiguring, 3-12
Plot files, 4-14, 7-160
Programmable Macro Language (PML), 1-1
Projects
transferring data between, 3-13
upgrading, 3-14
RCFCOPY command, 3-4
RCFUPDATE command, 3-10, 3-11
Reconfiguration, 3-5
Extracts, 3-21
Global Projects, 3-20
same references, 3-5
Transaction Database, 3-25
RECONFIGURE command, 3-4
RECONFIGURER, 3-1
Reference attributes, 3-9, 3-10
Reference number index, 3-10
loading from file, 3-11
saving to file, 3-11
Reference Number Index
listing, 3-5, 3-6
References
between databases, 3-9
Relevant User Guides, 1-1
REPLICATE command, 1-1
RESETXREFS command, 3-14
Root element, 3-11
SAMEREF option, 3-5
Source database
for reconfigure operation, 3-1, 3-2
TO command, 3-3, 3-13, 3-20
Transaction elements
TRDAY (Command Date Day), 5-3
TRFAIL (Transaction Failure), 5-11
TRFLST (Transaction Failure List), 5-11
TRINCO (Transaction Incoming Command), 5-
4
TRLOC (Transaction Location), 5-3
TRMESS (Transaction Message), 5-11
TRMLST (Transaction Messages List), 5-11
TRMONT (Command Date Month), 5-3
TROPER (Transaction Operation), 5-9
TROUCO (Transaction Output Command), 5-6
TRSLST (Transaction Success List), 5-11
TRSUCC (Transaction Success), 5-11
Index
VANTAGE PDMS ADMIN index-iii
Version 11.6SP3
TRUSER (Transaction User), 5-3
TRYEAR (Command Date Year), 5-3
Transferring data
to a new version of PDMS, 3-1
Upgrade macros, 3-14
VB Command, 3-7
Very Brief output mode, 3-7
World, 4-8
World elements
ACRW (Access Control Rights), 4-9
DBSTWL (DB Set), 4-6
FTWL (Font), 4-3
GLOCWL (Global Location), 4-19
GROWL (Global Role), 4-18
GSTAT (Global Status), 4-16
GSTWLD (Global Stamp), 4-21
GTMWL (Global Team), 4-16
LCOMW (Communications), 4-12
MDBW (MDB), 4-6
RFWL (Runfile or Module), 4-3
ROWL (Role), 4-7
STAT (Project Status), 4-3, 4-12
STWLD (Stamp), 4-8
TMWL (Team), 4-4
TRMSGW (Transaction Message), 5-3
USWL (User), 4-5
XREF command, 3-14

ADMIN Command Reference Manual PDF

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ADMIN Command Reference Manual PDF

Hochgeladen von

Copyright:

Verfügbare Formate

PDMS11.

6SP3/Admin Command Reference Manual

Das könnte Ihnen auch gefallen