You are on page 1of 242
PDMS Admin Admin Command Reference Manual Version 11.6SP3 PDMS11.6SP3/Admin Command Reference Manual Issue 300406

PDMS Admin

Admin Command Reference Manual

Version 11.6SP3

PDMS Admin Admin Command Reference Manual Version 11.6SP3 PDMS11.6SP3/Admin Command Reference Manual Issue 300406

PDMS11.6SP3/Admin Command Reference Manual Issue 300406

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

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.

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

DICE Errors

  • 2.1 ...................................................................................................................

2-1

  • 2.2 Commands...........................................................................................................

DICE

2-1

  • 3 Reconfiguration.............................................................................................

3-1

  • 3.1 The Reconfiguration

Process........................................................................................

  • 3.2 RECONFIGURER.......................................................................................

Starting up

  • 3.3 Administrative and Querying Commands

.....................................................................

  • 3.4 Reconfiguration....................................................................................................

Basic

  • 3.4.1 Reconfiguring a Single

Database.................................................................

  • 3.4.2 Specifying the Source Database

..................................................................

  • 3.4.3 Specifying the Destination DB

......................................................................

  • 3.4.4 Specifying What Will be Copied

...................................................................

  • 3.4.5 Starting the Reconfiguration

Process...........................................................

  • 3.4.6 Example of a Simple Reconfiguration

..........................................................

  • 3.5 Using the SAMEREF Option

.........................................................................................

  • 3.6 Using the SESSIONS Option

........................................................................................

  • 3.7 Listing the Reference Number Index

............................................................................

  • 3.8 Global Projects

..............................................................................................................

  • 3.9 Controlling RECONFIGURER

Output...........................................................................

  • 3.10 Copies and Reconfigured Copies of DBs

.....................................................................

  • 3.10.1 CopiesÖÖÖÖ.............................................................................................

  • 3.10.2 Reconfigured Copies

....................................................................................

  • 3.11 Advanced Reconfiguration

............................................................................................

  • 3.11.1 References Between

Databases..................................................................

3-1

3-1

3-2

3-2

3-2

3-3

3-3

3-4

3-4

3-5

3-5

3-6

3-6

3-7

3-7

3-8

3-8

3-9

3-9

3-9

  • 3.11.2 Updating References into a Reconfigured

Database.................................

  • 3.11.3 Saving the Reference Number Index

.........................................................

  • 3.11.4 Copying Parts of

Databases.......................................................................

  • 3.11.5 Copying Groups

..........................................................................................

  • 3.12 Transferring Data Between Projects

...........................................................................

3.13

Upgrading a

Project.....................................................................................................

3.14

Reconfiguration

Messages..........................................................................................

  • 3.14.1 Standard Information

Messages.................................................................

  • 3.14.2 General Format of Pass 2 Error

Messages................................................

  • 3.14.3 Codes Used to Identify Message

Types.....................................................

  • 3.15 Database Transfers between Computers

...................................................................

  • 3.16 Binary and Character

Files..........................................................................................

  • 3.17 The Transfer

Process..................................................................................................

3-10

3-11

3-11

3-13

3-13

3-14

3-17

3-18

3-18

3-19

3-19

3-20

3-20

  • 3.18 Reconfiguring a Global Project

...................................................................................

  • 3.19 Reconfiguring Extracts

................................................................................................

  • 3.19.1 Outputting Changes Only

...........................................................................

  • 3.19.2 The SAMEREF

Option................................................................................

  • 3.19.3 The SESSIONS

Option...............................................................................

3-20

3-21

3-21

3-21

3-21

Contents

  • 3.19.4 Reconfiguring a Single Extract

...................................................................

  • 3.19.5 Reconfiguring a Family of

Extracts.............................................................

  • 3.19.6 The RCFUPDATE

command......................................................................

3-22

3-22

3-23

  • 3.19.7 Example of Reconfiguring a Three Level

Extract.......................................

  • 3.19.8 Reconfiguring the Transaction Database in a Global Project

....................

3-23

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.2.2 Structure of the Global Database

...............................................................

4-12

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.4 TRUSER and TRLOC

elements....................................................................................

5-3

5-3

  • 5.5 TRINCO element (Input

Command)..............................................................................

5-4

  • 5.6 TROUCO element (Output

Command).........................................................................

  • 5.7 TROPER element (Operation)

......................................................................................

5-6

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

6.3

Project

Administration....................................................................................................

Global Project

Administration........................................................................................

  • 6.4 Definition...........................................................................................................

Module

6-1

6-2

6-2

6-3

  • 6.5 Definition................................................................................................................

Font

6-3

Querying

  • 6.6 ........................................................................................................................

  • 6.7 General PDMS

Commands...........................................................................................

6-3

6-3

  • 6.8 Data Integrity Checking

.................................................................................................

  • 6.9 Reconfiguration..............................................................................................................

6-3

6-4

  • 7 Command

Details..........................................................................................

7-1

  • 7.1 Conventions Used in the Syntax

Graphs......................................................................

  • 7.2 Notes on Syntax Graphs

...............................................................................................

  • 7.3 Detailed Descriptions of

Commands.............................................................................

ACCESS (Project definition)

................................................................................................

ACRADD (Project

definition)................................................................................................

7-1

7-2

7-3

7-4

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

BACKTRACK (Project Administration)

................................................................................

7-14

7-15

BRIEF

(Reconfiguration)......................................................................................................

CANCELCOMMAND (Global Project CDESC (Project definition)

Administration).........................................................

.................................................................................................. CHANGE (Project definition)

............................................................................................... CHECK (Data Integrity Checking)

.......................................................................................

CHECKOPTION (Data Integrity Checking)

.........................................................................

CNAME (Project

definition)..................................................................................................

COPY (Project

definition).....................................................................................................

7-17

7-18

7-19

7-20

7-24

7-27

7-31

7-33

Contents

CREATE (Project definition)

7-35

7-42

 

DADD (Project

7-43

DEALLOCATE (Global Project Administration - Hub

7-44

 

DEFER (Project

7-46

DELETE (Project

7-47

DREMOVE (Project definition)

7-50

DUMP

7-51

DUPLICATENAMES (Global Project Administration)

7-52

EDIT (Module definition)

7-54

ERRORFILE (Data Integrity Checking)

7-56

ERRORS

7-57

EXCHANGE (Project definition)

7-58

 

EXCLUDE (Project

7-59

EXPUNGE (Project

7-60

EXTERNAL (Data Integrity

7-62

 

EXTRACT (Project

7-64

FINISH (General PDMS

7-67

FONTDIRECTORY (Font definition)

7-68

 

FONTFAMILY (Font

7-69

FROM

7-71

FULL

7-72

GENERATE (Global Project Administration - Hub

7-73

GETWORK (General PDMS

7-75

HUBLOCATION (Global Project Administration - Hub

7-76

 

INCLUDE (Project

7-78

INITIALISE (Global Project

7-79

ISOLATION (Global Project Administration)

7-80

LIST

7-81

LOAD

(Reconfiguration)

7-84

LOCK

(Project

7-85

MAKE GLOBAL (Global Project

7-86

MAXERRORS (Data Integrity Checking)

7-87

 

MAXUSERS (Project

7-88

MAXWARNINGS (Data Integrity

7-89

MERGE CHANGES (Project

7-90

 

MESSAGE (Project

7-93

MODE (Data Integrity Checking)

7-94

MODULE (Module Definition)

7-95

7-97

NEW (Project definition and Global Project

7-98

 

NEW STAMP (Project

7-100

PING (Global Project

7-102

PREVOWNER (Global Project Administration - Hub only)

7-103

 

PROJECT (Project

7-105

PURGE (Project Administration and Global Project Administration)

7-107

QUERY

(Querying)

7-108

RCFCOPY

7-113

RCFUPDATE (Reconfiguration)

7-114

 

RCFUPGRADE

7-115

RECONFIGURE (Reconfiguration)

7-116

RECOVER (Global Project

7-118

REINIT (Reconfiguration)

7-121

7-122

7-128

VANTAGE PDMS ADMIN Command Reference Manual Version 11.6SP3

contents-iii

Contents

REMOVE (Project definition)

7-129

7-130

REORDER (Global Project

7-132

REPAIR (Global Project Administration)

7-133

REPLICATE (Project

7-134

RESETXREFS

7-137

REVERT (Project

7-138

SAVEWORK (General PDMS Command)

7-139

7-140

SORTALLOCATE

7-141

STATISTICS (Data Integrity

7-142

STATUSSESSION

7-143

STOP (Data Integrity Checking)

7-144

SYNCHRONISE (Global Project

7-145

SYSTAT

7-147

SYSTEMLOCATION (Global Project Administration - Hub

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

7-158

UNLOCK (Project

7-159

UPDATE (Global Project

7-160

UPGRADE (Reconfiguration)

7-162

VB

7-163

XREF

7-164

Index .................................................................................................................index-i

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

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.

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

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.

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

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 SET TEAM

Lists project information; there are a variety of options. 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 Q LOCK

Gives the name of the currently set team, if any. 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

The transfer of data takes place in two passes, the second of which is further divided into two phases:

PASS 1

PASS 2 - Phase 1

PASS 2 - Phase 2

The data is read from the source DB and written to a pair of intermediate files. The first file holds the element structures and the non-reference attributes, the other holds the reference attributes.

The first file is read by RECONFIGURER and used to recreate the original structures in the destination DB, including setting of the non- reference attributes.

The second intermediate file is read and its contents used to set all reference attributes in the destination DB and to perform insertion operations.

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

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

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

The following example illustrates the use of the SAMEREF option:

FROM DB MASTER/DESIGN TO FILE /F1 /F2 RCFCOPY ALL RECONFIGURE

DELETE DB MASTER/DESIGN CREATE DB MASTER/DESIGN DESI DBNO nn

FROM FILE /F1/F2 TO DB MASTER/DESIGN RECONFIG SAMEREF

  • 3.6 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

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 Satelliteís System database which is primary at the local Satellite.

  • 3.9 Controlling RECONFIGURER Output

You can control the format and extent of the output produced by RECONFIGURER during Pass 2 processing. The commands are:

VB

very brief output mode

BRIEF

brief output mode

FULL

full output mode

In VB (Very Brief) mode, a message is output as each element in the copy list is successfully created. If the copy command was RCFCOPY ALL, then a message is output for each element successfully copied into the World of the destination DB.

In BRIEF mode, all information output in VB mode is given, plus messages describing any errors that have occurred due to DDL changes.

Reconfiguration

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

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

HREF /E1-N2 Branch /150-B1 DESIGN DB 1 CREF /150-B1 Nozz /E1-N2 DESIGN DB 2
HREF /E1-N2
Branch /150-B1
DESIGN DB 1
CREF /150-B1
Nozz /E1-N2
DESIGN DB 2

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

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

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 FROM DB MASTER/DESIGN TO DB MASTER/DESNEW RCFCOPY ALL RECONFIGURE DUMP /DUMP2

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

If a number of databases have been reconfigured, the dump file will record the 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

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

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 TO FILES /TEMP1 /TEMP2

RCFCOPY ALL

RECONFIGURE

and in the destination project:

FROM FILES /TEMP1 /TEMP2

TO DB /CATNEW RCFCOPY ALL RECONFIGURE

Specify source DB. Only pass 1 of reconfiguration to be carried out; partially reconfigured data to be stored in named files.

Partially reconfigured data to be recovered from named file; pass 2 of reconfiguration to be done.

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

In the source project:

FROM DB ANSI/MASCAT TO FILES /REC1A /REC1B RCFCOPY ALL

RECONFIGURE

FROM DB CIVIL/STRUC4 TO FILES /REC2A /REC2B RCFCOPY ALL

RECONFIGURE

FROM DB VESSEL/V25CT TO FILES /REC3A /REC3B RCFCOPY /SITE-A

RECONFIGURE

and in the destination project:

FROM FILES /REC1A /REC1B TO DB CATAL/MAIN

RECONFIGURE

FROM FILES /REC2A /REC2B TO DB STEEL/MAIN

RECONFIGURE

FROM FILES /REC3A /REC3B TO DB EQUIP/MAIN

RECONFIGURE

RCFUPDATE DB STEEL/MAIN RCFUPDATE DB EQUIP/MAIN

  • 3.13 Upgrading a Project

Copies the Catalogue DB first

Copies the Design DB

Copies the Site

Creates Catalogue DB

Creates Design DB

Creates equipment item

Gives correct cross-references

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

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 From files /REC2A /REC2B Xref /REC2X

Reconfiguration

Reconfigure To db ALANC/ACPROP From files /REC3A /REC3B Xref /REC3X Reconfigure To db TAMH/THPROP From files /REC4A /REC4B Xref /REC4X Reconfigure To db TAMH/PROP_ATEST From files /REC5A /REC5B Xref /REC5X Reconfigure Reset with /REC1X Resolve db STANA/SAPROP Reset with /REC2X Resolve db DEREKF/DFPROP Reset with /REC3X Resolve db ALANC/ACPROP Reset with /REC4X Resolve db TAMH/THPROP Reset with /REC5X Resolve db TAMH/PROP_ATEST Finish

Output macro Write íUpgrading project CJB í

Write íFrom PDMS10 to PDMS11 í Write íOutput phase í

$R6

UPGRADE ON From db STANA/SAPROP

To files

/REC1A /REC1B

Copy all

Reconfigure

From db DEREKF/DFPROP

To files

/REC2A /REC2B

Copy all Reconfigure From db ALANC/ACPROP

To files

/REC3A /REC3B

Copy all

Reconfigure From db TAMH/THPROP

To files

/REC4A /REC4B

Copy all

Reconfigure

From db TAMH/PROP_ATEST

To files

/REC5A /REC5B

Copy all

Reconfigure

Reconfiguration

  • 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

  • 3.14.1 Standard Information Messages

The progress-monitoring messages, which indicate the stages reached during the reconfiguration, are self-explanatory. They are:

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

*** Pass two completed *** ***Reconfiguration Completed

After the reconfiguration has been completed, a summary of any problems found 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

  • 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

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

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

  • 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

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

MASTER

   

EXT

EXTBOT

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

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

(Note that the REFRESH, REVERT and MERGE CHANGES commands have not been shown below.)

Reconfiguration

FROM DB CTBATEST/MASTER TO FILE /MASTERA /MASTERB RCFCOPY ALL RECONFIG SESSIONS

FROM DB CTBATEST/EXT TO FILE /EXTA /EXTB RCFCOPY ALL RECONFIG SESSIONS

FROM DB CTBATEST/EXTBOT TO FILE /EXTBOTA /EXTBOTB RCFCOPY ALL RECONFIG SESSIONS

FROM FILE MASTERA /MASTERB TO DB CTBATEST/MASTER RECONFIG

FROM FILE EXTA /EXTB TO DB CTBATEST/EXT RECONFIG

FROM FILE EXTBOTA /EXTBOTB TO DB CTBATEST/EXTBOT RECONFIG

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

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

FROM DB CTBATEST/MASTER TO FILE /MASTERA /MASTERB RCFCOPY ALL RECONFIG SESSIONS

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

FROM DB CTBATEST/EXT TO FILE /EXTA /EXTB RCFCOPY ALL RECONFIG SESSIONS

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

FROM DB CTBATEST/EXTBOT TO FILE /EXTBOTA /EXTBOTB RCFCOPY ALL RECONFIG SESSIONS

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

  • 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

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.

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

/* WORLD World /*SC /*ST /*ACR /*T /*U /*M /*DS /*RO SCOW STWLD ACRW TMWL USWL
/*
WORLD
World
/*SC
/*ST
/*ACR
/*T
/*U
/*M
/*DS
/*RO
SCOW
STWLD
ACRW
TMWL
USWL
MDBW
DBSTWL
ROWL
Scope
Stamp
ACR
Team World
User World
MDB World
DB Set
Role
World
World
World
World
Wo rld
FTWL
SCOPE
STAMP
ACR
ACRST
TEAM
MDB
DBSET
ROLE
USER
Font
Scopes
Stamps
ACRs
ACR
Teams
MDBs
DB Sets
Roles
Users
World
Groups
FNTF
DBLI
USLI
TMLI
EXTLI
STLST
ACRL
Font
DB
User
Team
Extract
DB
DBSTL
DBL
PEROP
Stamp List
ACR Lists
Files
Lists
Lists
Lists
Lists
DBs
DB List
Perops
DB
DBs
DB
DBs
Figure 4-1
The System Database
/*S STAT Status World RFWL Module World RUNF Modules
/*S
STAT
Status World
RFWL
Module
World
RUNF
Modules

Runfile information: you can only modify these elements using the MODULE and EDIT commands

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

The System and Global Databases

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%/

The System and Global Databases

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

The System and Global Databases

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

Description

unset

120 character text

Projid

unset

3 character text

Fcpyref Nulref Bcpyref Nulref Extractno n Extract owner

/name

Variant false

Controlled

false

Hccnt

Extract list changes count Integer =< 999999

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 Description

unset 120 character text

Acrli

unset List of ACRs and ACRGRPs

The System and Global Databases

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

Description

unset

120 character text

The DB Set World (DBSTWL)

Attributes

Name

/*DS

Lock

false

Owner /*

The DB Set Element (DBSET)

Attributes

Name

/name

Lock

false

Owner

/*DS

Description

unset

120 character text

The System and Global Databases

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

Description

unset

120 character text

The Perop Element (PEROP)

Attributes

Name

/name

Lock

false

Owner

/name

Affirm

true

Opcreate

ignore

Opmodify

ignore

Opdelete Opclaim ignore

ignore

Opissue ignore

Opdrop

ignore

Eclass

unset Element Class

Aclass

unset Attribute Class

Condition unset

Acrmessage

unset

The System and Global Databases

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

Description

unset

120 character text

Scosel

unset Scope selection

PML expression

The Stamp World (STWLD) (Not used in Global projects)

Attributes

Name

/*ST

Lock

false

Owner /*

The Stamp Element (STAMP)

Attributes

Name

/name

Lock

false

Owner

/*ST

Desc

unset

Func

unset

Purp

unset

Setdat

unset

The System and Global Databases

The Stamp List Element (STLST)

Attributes

Name

/name

0

Lock

false

Owner

/name

Stlsf

Nulref DB reference

Stsess

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

 

Description unset

120 character text

Roleref

Nulref Role name

Scoperef Nulref Scope name

The ACR Group Element (ACRST)

Attributes

Name

/name

Lock

false

Owner

/*ACR

Description

unset

120 character text

The ACR List Element (ACRL)

Attributes

Name

/name

Lock

false

Owner /name

Acrf

list of references of ACRs in the ACR Group

The System and Global Databases

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

The System and Global Databases

/* WORLD World /*S /*DS /*RO /*SC /*U /*ACR /*T /*LC /*M STAT DBSTWL ROWL SCOW
/*
WORLD
World
/*S
/*DS
/*RO
/*SC
/*U
/*ACR
/*T
/*LC
/*M
STAT
DBSTWL
ROWL
SCOW
USWL
ACRW
TMWL
LCOMW
MDBW
Status World
DB Set
Role
Scope
User World
ACR
Team
Comms
MDB World
World
World
World
World
World
World
(empty)
(empty)
RFWL
FTWL
USER
DBSET
SCOPE
ACR
ACRST
MDB
Modules
Fonts
Users
DB Sets
Scopes
ACRs
LCTIML
LCOMC
LCOML
ACR Sets
MDBs
World
World
Event
Daemon
Comms
Timer
config
Links
RUNF
FNTF
TMLI
EXTLI
ACRL
Modules
Font
Team
Extract
DB
DBSTL
DBL
ACR Lists
LCTIMD
LCOMD
Families
Lists
Lists
DBs
DB List
Timings
Scheduled
Updates
Runfile information: you can
only modify these elements
using the MODULE and EDIT
commands
DB
DBs

Figure 4-2

The Local System Database in a Global Project

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

The System and Global Databases

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

Note:

text(120)

120 character text:

current Location Reference

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.

The System and Global Databases

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

Description

unset 120 character text

Locrf

/name Name of Location which has comms link

Timer

with current Location frequency of update events 120 character text:

Times

(See below) 0 Time window start

Timee

2400 Time window end

Timei

30

Interval in seconds between

Timeo

10

communication attempts Number of re-tries

Execb

unset

120 character text: name of

Execa

unset

script to be run before updates are transferred (optional) 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.

The System and Global Databases

The Timer values are:

Minutes past the hour Hours Days Months Days of the week

For example:

0 - 59 0 - 23 1 - 31 1 - 12 0 (Sunday) - 6

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

Timer '12 10,12,14,16,18 *

1,5 '

specifies 12 minutes past the hours given, 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

The System and Global Databases

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

Description

unset

120 character text

Locrf

/name

Reference to Location communicating

Lendti

with current Location 604800 Command timeout period, in seconds

Lmaxtr

100

(default is 7 days in seconds) 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.

The System and Global Databases

WORLD World /*GT /*GST /*GS /*GL /*G RO GSTAT GLOCWL GROLW GTMWL GSTWLD Global Global Global
WORLD
World
/*GT
/*GST
/*GS
/*GL
/*G RO
GSTAT
GLOCWL
GROLW
GTMWL
GSTWLD
Global
Global
Global
Global Status
Location World
Team World
Stamp
World
Role World
World
ROLE
TEAM
STAMP
Roles
Teams
Stamps
G RPLI
LOCLI
LNKLI
Group List
Location
Links List
List
PEROP
DBLI
STLST
Perops
DB List
Stamp
List
GRP
LOC
LNK
Groups
Locations
Links
DB
DBs
DBLOC

Figure 4-3

Structure of the Global System Database.

GSTAT Element (GSTAT)

Only one /*GS element can exist in the database and it is inherited from the STAT element in the Standard System Database.

Attributes

Name

/*GS

Lock

false

Owner

/*

Prjnumber

unset Project number:

17 character text

Maxusers

999999

Prjdesc

unset Project description

120 character text

Charset

-370086

Hccnt

Extract list changes count Integer =< 999999

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.

The System and Global Databases

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

The System and Global Databases

DBLOC Element

Attributes

Name

/name

Type

DBLOC

Lock

false

Owner

/name DB element

Locrf

/name Name of Primary Location

Prvrf

Name of previous

Propg

Primary Location (normally unset) 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

Description

unset 120 character text

The Perop Element (PEROP)

Attributes

Name

/name

Lock

false

Owner

/name

Opcreate

ignore

Opmodify

ignore

Opdelete Opclaim ignore Opissue ignore

ignore

Opdrop

ignore

Eclass

unset Element Class

Aclass

unset Attribute Class

Condition unset

 

Acrmessage

unset

The System and Global Databases

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