VANTAGE PLant Design ADMIN User Guide - cadfamily.com User Guide.pdf · local AVEVA SOLUTIONS office. See . VANTAGE PDMS ADMIN User Guide 1-1 Version 11.6 . Introduction to this Manual

PDMS ADMIN User Guide

Version 11.6

Pdms1160/ADMIN User Guide Issue 09:09:04

PLEASE NOTE:

AVEVA Solutions has a policy of continuing product development: therefore, the information contained in this document may be subject to change without notice. AVEVA SOLUTIONS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS DOCUMENT, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. While every effort has been made to verify the accuracy of this document, AVEVA Solutions shall not be liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance or use of this material.

This manual provides documentation relating to products to which you may not have access or which may not be licensed to you. For further information on which Products are licensed to you please refer to your licence conditions.

© Copyright 1997 through 2004 AVEVA Solutions Limited All rights reserved. No part of this document may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without prior written permission of AVEVA Solutions. The software programs described in this document are confidential information and proprietary products of AVEVA Solutions or its licensors.

For details of AVEVA's worldwide sales and support offices, see our website at http://www.aveva.com

AVEVA Solutions Ltd, High Cross, Madingley Road, Cambridge CB3 0HB, UK

http://www.aveva.com/

Revision History

Date Version Notes

March 2003 11.5 Document Rebranded. Minor text changes and updates. Sept 2003 11.5.1 MDB form update (New Rebuild gadget) Sept 2004 11.6 Revised

VANTAGE PDMS ADMIN User Guide Version 11.6

Revision History

VANTAGE PDMS ADMIN User Guide Version 11.6

Contents

1 Introduction to this Manual ......................................................................... 1-1 1.1 Who Should Read This Manual ................................................................................1-1 1.2 How to Use This Manual...........................................................................................1-2 1.3 Other Documentation................................................................................................1-3

2 Overview of PDMS ADMIN ........................................................................... 2-1 2.1 PDMS Projects...........................................................................................................2-1 2.2 Project Administration..............................................................................................2-1 2.3 ADMIN Elements ......................................................................................................2-2 2.4 Database Integrity Checking ....................................................................................2-2 2.5 Reconfiguration .........................................................................................................2-3

3 The PDMS Databases................................................................................... 3-1 3.1 Database Types..........................................................................................................3-1 3.2 PDMS Project Structure............................................................................................3-2 3.3 The Administration Databases.................................................................................3-3

3.3.1 The SYSTEM Database ...................................................................................3-3 3.3.2 The COMMS Database ....................................................................................3-3 3.3.3 The MISC Database .........................................................................................3-4

3.4 How the Model Databases are Related ....................................................................3-4 3.5 How Databases are Stored........................................................................................3-5 3.6 Teams and Users .......................................................................................................3-6 3.7 Database Access ........................................................................................................3-6 3.8 Multiple Databases (MDBs)......................................................................................3-7 3.9 How Databases are Updated ....................................................................................3-8

3.9.1 Updating Model Databases..............................................................................3-8 3.9.2 Updating the SYSTEM database ....................................................................3-8

3.10 CONTROLLED Databases .......................................................................................3-9 3.11 Database Sessions .....................................................................................................3-9

3.11.1 Backtracking and Merging Sessions ........................................................3-10 3.11.2 Using Stamps with Sessions.....................................................................3-10

4 The PDMS Database Management System ................................................ 4-1 4.1 Overview ....................................................................................................................4-1 4.2 Elements and Attributes...........................................................................................4-2 4.3 The DABACON Buffer ..............................................................................................4-3

5 Setting Up a New Project ............................................................................. 5-1 5.1 Summary....................................................................................................................5-1 5.2 Creating the Project Directory Structure.................................................................5-1 5.3 Setting the Environment Variables..........................................................................5-2

VANTAGE PDMS ADMIN User Guide Contents-i Version 11.6

Contents

5.4 Creating a Project ..................................................................................................... 5-3 5.4.1 The make Utility.............................................................................................. 5-3

5.5 The Completed Project.............................................................................................. 5-4

6 Designing a Project...................................................................................... 6-1

7 Creating the Main ADMIN Elements ........................................................... 7-1 7.1 Starting Up ADMIN ................................................................................................. 7-1 7.2 Summary ................................................................................................................... 7-3 7.3 The Admin Elements Form ...................................................................................... 7-3

7.3.1 Querying Attributes ........................................................................................ 7-3 7.3.2 Querying the Project........................................................................................ 7-4 7.3.3 Configuring the Admin Elements Form......................................................... 7-4

7.4 Sorting and Filtering ................................................................................................ 7-5 7.5 Teams and Users ...................................................................................................... 7-6

7.5.1 Creating Teams ............................................................................................... 7-6 7.5.2 Creating Users................................................................................................. 7-7 7.5.3 Modifying Attributes of Users and Teams ..................................................... 7-9 7.5.4 Copying Users and Teams............................................................................... 7-9 7.5.5 Deleting Teams and Users ............................................................................ 7-10

7.6 Databases ................................................................................................................ 7-10 7.6.1 Creating Databases ....................................................................................... 7-10 7.6.2 Modifying Database Attributes..................................................................... 7-13 7.6.3 Copying Databases ........................................................................................ 7-13 7.6.4 Including and Copying Foreign Databases .................................................. 7-14 7.6.5 Copying and Including from the Sample Project ......................................... 7-16 7.6.6 Deleting Databases........................................................................................ 7-16

7.7 Database Sets.......................................................................................................... 7-16 7.8 Multiple Databases (MDBs) ................................................................................... 7-18

7.8.1 Creating MDBs .............................................................................................. 7-18 7.8.2 Adding DB Sets.............................................................................................. 7-19 7.8.3 Modifying MDBs............................................................................................ 7-19

8 Multiwrite Databases and Extracts............................................................. 8-1 8.1 Simple MULTIWRITE Databases ........................................................................... 8-1 8.2 Extracts ..................................................................................................................... 8-2

8.2.1 Types of Extracts ............................................................................................. 8-2 8.2.2 Advantages....................................................................................................... 8-3

8.3 Extract Families ....................................................................................................... 8-3 8.4 Using Extracts .......................................................................................................... 8-5

8.4.1 Claiming........................................................................................................... 8-5 8.4.2 Refreshing ........................................................................................................ 8-7 8.4.3 Flushing ........................................................................................................... 8-7 8.4.4 Release ............................................................................................................. 8-8 8.4.5 Issue ................................................................................................................. 8-8 8.4.6 Drop.................................................................................................................. 8-8 8.4.7 Partial operations ............................................................................................ 8-9

8.5 Creating Extracts.................................................................................................... 8-10

Contents-ii VANTAGE PDMS ADMIN User Guide Version 11.6

Contents

8.5.1 Extract Naming and Numbering...................................................................8-12 8.5.2 Deleting an Extract ........................................................................................8-13 8.5.3 Extracts and Foreign Projects .......................................................................8-13 8.5.4 Adding Extracts to MDBs ..............................................................................8-13

8.6 Working Extracts.....................................................................................................8-13 8.6.1 Creating Working Extracts............................................................................8-13 8.6.2 Using Working Extracts ................................................................................8-15 8.6.3 Issuing from Working Extracts .....................................................................8-15 8.6.4 Extract Control...............................................................................................8-17

8.7 Variant Extracts ......................................................................................................8-18 8.7.1 Variants as Owners........................................................................................8-18

8.8 Extract Sessions ......................................................................................................8-18 8.8.1 Reverting Extracts .........................................................................................8-19 8.8.2 Merging Changes for Extracts.......................................................................8-20

8.9 Expunging................................................................................................................8-20 8.10 Limits .......................................................................................................................8-21

9 Using Stamps................................................................................................ 9-1 9.1 Stamps and the System Database............................................................................9-2 9.2 Creating Stamps........................................................................................................9-3 9.3 Modifying Attributes of Stamps................................................................................9-5 9.4 Copying Stamps.........................................................................................................9-5 9.5 Deleting Stamps ........................................................................................................9-6

10 Data Access Control (DAC) ....................................................................... 10-1 10.1 How to Use This Chapter........................................................................................10-1 10.2 ACRs, Roles and Scopes ..........................................................................................10-2

10.2.1 Permissible Operations (Perops) ..............................................................10-2 10.3 Creating Roles .........................................................................................................10-4 10.4 Permissible Operations ...........................................................................................10-5 10.5 Examples..................................................................................................................10-7

10.5.1 Messages about Access Denial by DACs................................................10-10 10.6 Creating Scopes .....................................................................................................10-10 10.7 ACRs and ACR Groups .........................................................................................10-11

10.7.1 Creating an ACR .....................................................................................10-11 10.7.2 Creating an ACR Group..........................................................................10-12

10.8 How ACRs are Applied..........................................................................................10-14

11 Project Administration ............................................................................... 11-1 11.1 Locking the Project Database .................................................................................11-1 11.2 The Options under Admin on the Main Menu.......................................................11-1

11.2.1 Abnormal Exits..........................................................................................11-2 11.3 Display .....................................................................................................................11-2 11.4 The Query Options ..................................................................................................11-2 11.5 The Settings Options...............................................................................................11-3 11.6 The Utilities Options...............................................................................................11-3

11.6.1 Integrity Checking ....................................................................................11-3 11.6.2 Sending Messages to Other Users............................................................11-3

VANTAGE PDMS ADMIN User Guide Contents-iii Version 11.6

Contents

11.7 The Project Options ................................................................................................ 11-4 11.7.1 Project Information................................................................................... 11-4 11.7.2 Replicating a Project................................................................................. 11-5 11.7.3 Deleting Phantom Users .......................................................................... 11-6

11.8 The Data Options on the Main Menu .................................................................... 11-6 11.8.1 Merging Sessions ...................................................................................... 11-7 11.8.2 Backtracking Sessions.............................................................................. 11-9 11.8.3 Inter-DB Macros ..................................................................................... 11-11

11.9 Distributed Databases .......................................................................................... 11-12 11.9.1 Global Databases .................................................................................... 11-13

12 Font Families.............................................................................................. 12-1 12.1 Introduction to Font Families ................................................................................ 12-1

12.1.1 Character Sets .......................................................................................... 12-1 12.1.2 Character Styles ....................................................................................... 12-2 12.1.3 User-Defined Fonts................................................................................... 12-3 12.1.4 Sloping Fonts ............................................................................................ 12-3

12.2 Setting Up Font Families ....................................................................................... 12-3

13 Data Integrity Checking ............................................................................. 13-1 13.1 Database Storage Statistics ................................................................................... 13-2 13.2 Preparatory Steps before Checking Starts ............................................................ 13-2 13.3 Using DICE ............................................................................................................. 13-3

13.3.1 Producing Statistics.................................................................................. 13-4 13.3.2 Checking External References ................................................................. 13-4 13.3.3 Using the Patch Option ............................................................................ 13-5 13.3.4 Checking Extract Claimlist Integrity ...................................................... 13-6 13.3.5 Maximum Errors ...................................................................................... 13-6 13.3.6 Selecting the Output Destination ............................................................ 13-6

13.4 Macros ..................................................................................................................... 13-7 13.5 DICE Output ........................................................................................................... 13-7

13.5.1 The Report Header ................................................................................... 13-8 13.5.2 The Error Report ...................................................................................... 13-9 13.5.3 The Report Summary ............................................................................. 13-10

14 Modules ...................................................................................................... 14-1 14.1 How Modules are Defined ...................................................................................... 14-1 14.2 The Module Definition Form.................................................................................. 14-1 14.3 Setting the DABACON Buffer Size........................................................................ 14-2

Appendix A: Menu Maps......................................................................................A-1

Index

Contents-iv VANTAGE PDMS ADMIN User Guide Version 11.6

1 Introduction to this Manual

This User Guide describes how to use the PDMS ADMIN module for PDMS Project Administration. PDMS ADMIN allows you to: • Set up new PDMS projects, controlling which users have access to

which databases. • Administer projects, including change management and setting

PDMS fonts. • Control user access to PDMS modules. • Check data integrity. • Reconfigure databases when necessary. This manual describes the PDMS concepts which you need to know about in order to set up and administer your PDMS projects. It describes how to use ADMIN via the graphical user interface (GUI): the commands underlying the interface are described in the VANTAGE PDMS ADMIN Command Reference Manual.

1.1 Who Should Read This Manual

This User Guide is written for the System Administrator who is responsible for setting up PDMS projects. System Administrators should be familiar with the general principles of PDMS. For example, they should be aware of the different modules and what they are used for, and should know about how to start up PDMS as a normal (non-administrative) user, giving a username and password, and specifying a Project Code and MDB. Ideally, System Administrators should attend a PDMS Administration Training course. For information about training courses, contact your local AVEVA SOLUTIONS office. See http://www.AVEVA.com/.

VANTAGE PDMS ADMIN User Guide 1-1 Version 11.6

http://www.aveva.com/

Introduction to this Manual

1.2 How to Use This Manual

The User Guide is not a tutorial, but it is based on a consistent example. If you are a new ADMIN user, you may like to set up a similar project, so that you can work through some of the example yourself. It is recommended that you at least scan through the whole manual to get an idea of the contents, and then refer to the sections you need in more detail. Chapter 2, Overview of PDMS ADMIN, describes the principles of how PDMS ADMIN is used. Chapter 3, The PDMS Databases, describes the different types of database and how they are related, how they are stored and how they are updated. Chapter 4, The PDMS Database Management System, gives some details of the internal structure of PDMS databases. It is not essential for you to know about these details at first, but it may be helpful at a more advanced stage. Chapter 5, Setting Up a New Project, Describes how to set up a new project, starting from a new installation of PDMS. Chapter 6, Designing a Project, describes some of the points you need to consider before you start creating elements in a new project, once it has been set up as described in Chapter 5. Chapter 7, Creating the Main ADMIN Elements, describes how to create the elements that you decided you needed after considering the points discussed in Chapter 6. Chapter 8, Multiwrite Databases and Extracts, describes how specific types of database may be modified by more than one user at a time. Chapter 9, Using Stamps, explains how to use stamps to mark database sessions, so making it easier to identify changes made from session to session. Chapter 10, Data Access Control (DAC), explains how access rights to databases can be restricted to specific groups (teams) of users. Chapter 11, Project Administration, summarises the options available from the main ADMIN menu. Chapter 12, Font Families, describes how to define the fonts used in DESIGN and DRAFT. Chapter 13, Data Integrity Checking, describes how to use DICE, the PDMS database integrity checking utility.

1-2 VANTAGE PDMS ADMIN User Guide Version 11.6


Chapter 14, Modules, describes how to edit the PDMS module definition supplied with the product, if you need to. Appendix A contains menu maps, and lastly there is an index.

1.3 Other Documentation

This manual assumes that you have already installed PDMS, as described in the VANTAGE PDMS Installation Guide. The commands underlying the interface are described in the VANTAGE PDMS ADMIN Command Reference Manual. Note: Sometimes you will want to reconfigure your databases.

Reconfiguration is a command level operation, and so it is described in the VANTAGE PDMS ADMIN Command Reference Manual. It is also possible to run DICE, the PDMS Database Integrity Checker, outside PDMS. There is no GUI for the stand-alone version of DICE, and more information is given in the VANTAGE PDMS ADMIN Command Reference Manual.

This manual does not describe every option on the forms and menus in detail. For more information, see the on-line help. If you have a licence for PDMS GLOBAL, you should refer to the VANTAGE Plant Design Global Management User Guide for more information.




2 Overview of PDMS ADMIN

2.1 PDMS Projects

The Project is a fundamental concept in PDMS, and all work takes place within a project. Everything that is defined in PDMS ADMIN is specific to a given project, although it is possible to read databases in another project. A PDMS project contains a number of database files. Each database file owns a number of elements: each element has a number of attributes. PDMS supports different database types (DESIGN, DRAFT, etc.). Each database type has a different database schema; that is, the element/attribute structure is different.

2.2 Project Administration

PDMS ADMIN allows you to carry out various administration tasks, including: • Creating and deleting database files. • Creating and deleting users. • Controlling the access that each user has to the project databases. • Grouping databases together into multiple databases (MDBs). • Marking database sessions with a stamp, to enable changes from

session to session to be identified. The administrative information about a PDMS project is held in a PDMS database called the System database. In carrying out the project administration, you will create, modify and delete elements in the System database.


Overview of PDMS ADMIN

2.3 ADMIN Elements

One of the main functions of ADMIN is creating and managing the PDMS ADMIN elements. The fundamental elements are Teams, Users, DBs (databases) and MDBs (multiple databases). DBs and Teams are closely related: a DB must be owned by a Team, and only the Users who are members of the owning Team have write access to the DB. MDBs are collections of DBs. When you enter a PDMS constructor module (DESIGN, SPOOLER, DRAFT or ISODRAFT) you must specify an MDB, and this defines which DBs you will be able to access. The System Administrator must set up MDBs in each project so that users can access all the DBs they require. Users are defined by an identifier and password, which allows them to enter PDMS. Users are normally members of Teams, which gives them write access to DBs owned by the Team, but a user who only needs read access does not have to be a member of a Team. In addition, you can optionally create other elements which can help administer a PDMS project, and give you more flexibility in controlling work flow and access rights: Extract Databases, including Working Extracts, allow users to Claim elements from a master DB, then Issue work back to the master DB when they are satisfied with the changes they have made. Variant databases allow users to try out different designs: the best can then be merged back into the master database. Stamps are used to mark database sessions at a specific time and date, enabling key dates to be more easily identified. Roles and Scopes are combined into Access Control Rights (ACRs), which give more precise control over users' access to databases. DB Sets are collections of DBs which can be handled as a single entity. For example, you could make a DB set containing several catalogue databases, which could then be added to MDBs all together.

2.4 Database Integrity Checking

The PDMS Database Integrity Checker, DICE, checks the internal structures of the project databases and reports any inconsistencies or faults within them. It can also check the consistency of the System



database, and produce statistical information about the effective use of the database storage capacity. The checks cover only the self-consistency of the stored elements in the database hierarchies. The consistency of the element attributes can be checked using the Data Consistency options in DESIGN and DRAFT.

2.5 Reconfiguration

PDMS databases can be reconfigured. This is necessary in the following cases: • To combine databases by copying parts of one into another. • To transfer databases between different projects. • In some cases, to enable corrupt databases to be recovered. Reconfiguration may also be necessary when a new release of PDMS is installed, although in this case macros which will reconfigure your projects automatically will normally be supplied with the product. Note: Reconfiguration is a command-driven operation: there is no GUI

provided. It is therefore described in the VANTAGE PDMS ADMIN Command Reference Manual.




3 The PDMS Databases

This chapter is an introduction to PDMS databases. You need to understand this information before you can set up a project.

3.1 Database Types

A PDMS project can contain the following types of database: Administration Databases

The SYSTEM database itself, which holds the access control data for the model data and modules. The COMMS database, which stores information about who is using which module and which model databases are available. The MISC database which stores inter-user messages, and inter-database macros.

Model Databases DESIGN databases which contain all the design information for the project. CATALOGUE databases which contain the project catalogue and specifications. PADD databases which contain data about drawings produced by DRAFT. ISOD databases which contain spool drawings produced by SPOOLER. PROPERTIES databases which can contain material properties, and can be referenced by the catalogue. DICTIONARY databases which contain the definitions of user-defined attributes (UDAs), as set up in LEXICON.

Each project can have only one of each type of administration database, but it can have any number of each type of model database.


The PDMS Databases

3.2 PDMS Project Structure

All the information about the databases in a PDMS project is held in a Project Directory. A project is identified by a three-character code. For example, the sample project supplied with the product is SAM. There are other directories associated with every project which store inter-database connection macros, DRAFT picture files and ISODRAFT files. The structure of a Project Directory and the naming convention for the other files are shown below, using SAM as an example. Note: This example shows the AVEVA Solutions naming conventions

for the directories. You can name them according to your own conventions, as long as the environment variables are correctly set. You cannot control the filenames: they will always be of the format prjnnnn, where prj is the project code, except that you can specify the filenumber (the nnnn part of the filename), see Section 7.6.1, Creating Databases.

sam000 samiso sampic sammac DFLTS

samsys samcom sammis sam001 samnnn

sam000 The project directory. The files under sam000 are: samsys The SYSTEM database samcom The COMMS database sammis The MISC database sam001 - samnnnn

Databases files which contain the actual model data. nnnn has a maximum of 8188, but numbers 7000 - 7999 are reserved for use by AVEVA Solutions, and numbers 8000 upwards are for system use.

samiso The directory which stores files needed by ISODRAFT.

sampic The directory which stores picture files produced by DRAFT.


The PDMS Databases

sammac The directory which stores inter-database connection macros. See Section 11.8.3.

DFLTS The PDMS project-specific defaults directory. For more information about the DFLTS directory, see the VANTAGE PDMS Installation Guide.

Project environment variables must be set to the project directories. For the sample project, the environment variables are set in the supplied evars.bat file. For example, the file will contain a line of the form:

set SAM000=c:\AVEVA\projects\sam000

This is the default setting, but is user definable on installation. For more information, see Section 5.2, Creating the Project Directory Structure.

3.3 The Administration Databases

3.3.1 The SYSTEM Database

There is one, and only one, SYSTEM database in the Project Directory. It holds administrative information about the composition and use of the project, including the following: • A list of all the databases which are available in the project. • A list of all Users who can access the databases, and the Teams to

which they belong. • A list of PDMS modules available in the project Note: The SYSTEM database is a multiwrite database, which means

that there may be more than one user in ADMIN at any time. PDMS manages access to multiwrite databases so that two users cannot try to modify the same part of the database at the same time. See Section 8.1 for more information about multiwrite databases.

3.3.2 The COMMS Database

The COMMS database stores the information about who is using which module and which databases are current. Each user has a separate area of the COMMS database, which can be accessed in write mode, and so can record module changes etc. Each user has read access to the other users’ areas, and so can find out about other users in the project.


The PDMS Databases

Note: The COMMS database is a single-access database. Users queue for the COMMS database once, on entry into PDMS.

3.3.3 The MISC Database

The MISC database is used to store inter-user messages, and inter-database macros (see Section 11.8.3 for more information about inter-db macros). This database can only be opened in write mode by one user at a time, but many users can read from it. All users need to be able to write to this database, but only when they are sending messages or writing inter-database macros, or deleting messages and macros. All users can read from the database at any time. Note: The MISC database is a single-access queued database, that is a

user wishing to write to the MISC database must wait until any other users writing to it have finished.

3.4 How the Model Databases are Related

The data in a model database will often reference data in other types of database: • DESIGN databases derive information about design components

from the CATALOGUE databases. • PROPERTIES databases are referenced by CATALOGUE and

DESIGN databases. • PADD and ISOD databases contain references to the design model. • DICTIONARY databases hold definitions which are referenced from

DESIGN, CATALOGUE or PADD databases. The pointers between the various types of database are illustrated in Figure 2-1.


The PDMS Databases

PROPERTIES DB

CATALOGUE DB

DESIGN DB

PADD DB

DICTIONARYDB

ISOD DB

Figure 2-1 Relationships between the database types

3.5 How Databases are Stored

Each database is a separate file, stored in the Project Directory. The filenames have the format

xxxnnnn_mmmm where xxx is the Project Code, for example, abc, and nnnn is a number from 1 to 6999. nnnn is the database number and mmmm is the extract number. By default, the databases are given the next available number, but you can specify what number will be used when you create the database; see Section 7.6.1, Creating Databases. Databases can be stored in a different area, that is a different directory from the Project directory. This may be necessary, for example, if disk space is a problem. The directory must be created before the database is created, and an environment variable set, for example:

xxxnnn set to pathname

where xxx is the Project Code, for example, abc, and nnn is the area number which must be in the range from 1 to 999, 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. For information about Extract database files, see Chapter 8.


The PDMS Databases

3.6 Teams and Users

Each database belongs to one Team only. Ownership of a database is established by the naming convention for databases: database names have the format

teamName/databaseName Users are defined by identifiers and passwords which they enter when they start up PDMS. Users are normally members of Teams. A User must belong to the Team owning the database in order to have write access to it. A team may have only one User, or even none, in which case only Free Users will be able to write to the Databases owned by the Team. A User may belong to many teams. Note: Further access restrictions may be set using Data Access Control

(DAC). See Chapter 10.

3.7 Database Access

This section introduces the basic PDMS database access mechanism. For information about more extensive Data Access Control, see Chapter 10. Database access depends on attributes of the User and of the Database Users can be FREE or GENERAL: FREE Users May enter all modules.

May update any databases. GENERAL Users May not enter the Restricted modules; usually the

administration modules ADMIN and LEXICON. May only modify databases for teams of which they are members.

Note: User privileges also control access to modules; see Chapter 14, Modules.

Databases can be UPDATE or MULTIWRITE: UPDATE Allow one writer and n readers. MULTIWRITE Allow m writers and n readers. For more information

about multiwrite databases, see Chapter 8. DESIGN, CATALOGUE, DRAFT (PADD) and ISODRAFT databases can be multiwrite. The SYSTEM database is always multiwrite.


The PDMS Databases

Both UPDATE and MULTIWRITE databases can also be CONTROLLED, in which case write access is controlled externally to PDMS. See Section 3.10. • You can change an update database to multiwrite at any time. • You can only change a multiwrite database to update if no extracts

have been created from it. See Section 8.2 for more information about extracts.

3.8 Multiple Databases (MDBs)

To control what data a user can see, databases are grouped into Multiple Databases (MDBs). A project will contain at least one MDB. A database may be a member of any number of MDBs. An MDB must contain all the data that the user needs to access. For example, for a DESIGN user, the MDB must contain a Catalogue database and the Design database on which the user is going to work. In addition, the MDB should contain all other DESIGN databases with data in the same physical volume, which will ensure the accuracy of clash checking, and all other DESIGN databases which will have connections to the user’s design area. Many users can access the same MDB. There are different ways of allowing access to MDBs: some options are described below: 1. One MDB per User. The DB with write access must be the first DB

of that type (DESIGN, DRAFT, etc.) in the MDB’s list of members. This option may be suitable for large projects with many DBs and Users.

2. One MDB with many users. In this case, the System Administrator can create the first-level elements in the DB, for example, Sites or Departments, which avoids having to use the DEFER and CURRENT options to move the required database to the top of the list (see Section 7.7). This option is often suitable for small to medium projects with few DBs and Users, or where multiwrite DBs are being used.

3. MDBs for special purposes. For example, an MDB containing Piping data only for MTO production, etc.

The order of databases in an MDB is important. In a new project, if there is more than one database of the type you are going to write to, PDMS will try to write to the first one in the MDB list. This means that when you start to create top-level elements (Sites, Departments, etc.) they will


The PDMS Databases

be created in the first database in the MDB. This means that you must have write access to the first database in the list.

3.9 How Databases are Updated

3.9.1 Updating Model Databases

This section describes how the model databases, that is Design, Draft (PADD), Isodraft, Catalogue, Properties and Dictionary databases, are updated. When a PDMS user adds, changes or deletes items, the changes are not immediately written into the database. New or modified items are stored in memory. If there is insufficient memory available, data may be paged out to a temporary file. When the user does a SAVEWORK, the data is written back to the end of the database. If the user changes module or exits from PDMS without saving work, the changes stored in memory or in the temporary file will be discarded and the effects of all commands given while in the working module since the last SAVEWORK will be lost. A reader of a database will only see changes after: • the writer does a SAVEWORK, FINISH or module switch and • the reader does a GETWORK or module switch. Until the reader

does a GETWORK, the data will appear exactly as it was before the SAVEWORK.

3.9.2 Updating the SYSTEM database

The SYSTEM database stores information about the users, teams, databases and module definitions in a project. The information held in the System database is only updated by System Administrators with access to ADMIN, never by other users, although all users will need read access to the information. Entering ADMIN opens the SYSTEM database in write mode, and all other modules open it in read mode. • The System database is updated in a slightly different way from the

model databases. To ensure consistency, ADMIN automatically does a SAVEWORK after certain commands. Leaving ADMIN without saving work will discard changes made since the last user or system SAVEWORK.


The PDMS Databases

3.10 CONTROLLED Databases

If a database is defined as a CONTROLLED database, then all updates are controlled externally to PDMS. Both UPDATE and MULTIWRITE databases can be CONTROLLED. The external system is accessed via an EDMSlink program, which must be supplied by the user. Users must claim elements in order to change them on CONTROLLED databases. The EDMSlink program is activated by PDMS when a CLAIM or release is made. It is totally up to the user as to what the EDMSlink does. Normally it will link into a user’s central control system. Only Primary elements can be claimed: see the appropriate reference manual for information about Primary elements in each module. For controlled DBs, claiming is based on element names; that is, until an element is named, no restrictions exist. However when a Primary element is named, the external system checks whether the name exists, and in future the name is always used to claim out the element. The claim is only made the first time an element is updated. The element remains claimed until it is explicitly released.

3.11 Database Sessions

Each time a user does a SAVEWORK or module switch, a new session will be created for that user for each modified database. Sessions are numbered sequentially for each database. Each database is sessioned individually; for example, a SAVEWORK on databases TEAM1/DB1 and TEAM1/DB2 may create a new session number 106 for TEAM1/DB2 and session number 289 for TEAM1/DB2. If at the next SAVEWORK only TEAM1/DB1 has been modified then its session number will be incremented to 107, and that for TEAM1/DB2 will remain unchanged. The user name and current date are stored against each session. Optionally, in the GUI modules, the user can add a session comment. In DESIGN, DRAFT, SPOOLER and PARAGON, users can compare their current data with that at some previous session or date, and query the session in which given attributes and elements changed. Note on Session Numbering

For any database, Session 1 is when the database is created, and Session 2 is when the World is created. This means that the first user session is Session 3. The current session, before a savework is done, is session 0.


The PDMS Databases

3.11.1 Backtracking and Merging Sessions PDMS sessions enable a history of changes to the database to be recorded. You can backtrack a database to a previous session. When a new session is made, the changed data is appended to the end of the database file. Appending updated data to files will increase the disk space required. If this is a problem, you merge the intermediate session information for each database. For more information, see Section 11.8.2.

3.11.2 Using Stamps with Sessions You can use a stamp to mark database sessions, either by a specific time and date, or by session. You can use stamps in many ways. For example, you can produce drawings on which all revisions made since an earlier stamped session are highlighted, or backtrack a database to a previous stamped session. For more information, see Section 9.


4 The PDMS Database Management System

This chapter gives an overview of the PDMS Database Management System and the way in which it builds databases. This information may be useful to experienced users, but it is not essential for using PDMS ADMIN. DABACON (DAtaBAse CONstructor) is the PDMS database management system. It is used to construct, navigate and interrogate a database structure. Most of the analytical functions of database integrity checking are concerned with checking that the data is correctly structured according to the DABACON rules.

4.1 Overview

The principal data objects in DABACON are element instances. In general, these elements represent physical entities such as pipes or valves. These elements are associated with one another in a hierarchy: for example, a Pipe will own Branches which own Valves. Each element has attributes to describe the properties of the item it represents: for example, Temperature, Pressure, Length. The valid element types, and their attributes, are defined in the database schemas. There are different database schema files for each databases type, for example, Catalogue and Design databases. Each database consists of a single hierarchy of elements. The root of this structure is referred to as the World. Database changes are made during a database session. On SAVEWORK, FINISH or module switch, the changes are appended to the database. If the user QUITs rather than saving a session, the changes will be lost. Multiwrite databases allow two or more users to write to the same database at the same time. The system checks that no two users write to the same element. The changes are then written back to the database as new sessions in the normal way. Note: Certain attributes are excluded from this rule, for example,

Connection References.


The PDMS Database Management System

4.2 Elements and Attributes

DABACON databases contain element instances. An element instance will be of a specified type. The type of the element determines what attributes it may have. For example, a Box could have attributes XLEN, YLEN, ZLEN and position. In PDMS, a Box has many more attributes than this! The database schema defines: • What element types can exist. • What attributes are allowed for each element type. • The permitted element relationship within the hierarchy. For

example, an Equip item is allowed to own a Box, but a Box is not allowed to own an Equip.

Attributes are of different types. The type of an attribute is relevant when accessing attribute values within a PML expression. For example, the expression (XLEN EQ TRUE) is invalid since XLEN is a real rather than a logical. The types of attribute allowed are:

Type Example Integer ATOL Arc tolerance Integer array DPLS List of valid design points Real ABOR Arrive bore Real array HEIL Height limits Logical INFG Insulation flag Logical array DSET Displacement limits Reference PSPE Pipe specification Reference array BLRF Bolt reference array Text PLTX Projection line text Position PTOP Top of pipe Direction ADIR Arrive direction Orientation LAXE Local axes

Reference type attributes are pointers to other elements; for example, from a Nozzle to a Branch. They are also used to reference between databases; for example, from a Design item to its Catalogue representation. Within PDMS, the valid attributes for an element can be output by giving the command Q ATT. As well as the attributes defined in the


The PDMS Database Management System

schema, there are user-defined attributes (UDAs) and pseudo-attributes. Pseudo-attributes are not output by Q ATT. Pseudo-attributes are calculated internally by PDMS. For example, at a Flange the user may query the p-point information or the arrive/leave tube length. A full list of pseudo-attributes is provided in the VANTAGE Plant Design Software Customisation Reference Manual. Each element instance has a unique reference number. This number never changes, and can even be preserved when the database is reconfigured, and so it can be used to reference a PDMS element from outside PDMS.

4.3 The DABACON Buffer

The DABACON buffer is an area of data storage space within each module, reserved for holding pages of data which have been read from databases or which are to be written to databases. Data transfers between the databases and the module always take place in exact multiples of one page. The larger the DABACON buffer, the higher the chance that a previously used page can be found in the buffer and reused, rather than having to be physically fetched from disk again. Therefore, other things being equal, as the buffer size is increased so disk I/O should decrease, possibly at the expense of slightly increased CPU usage. However, as the buffer is increased the computer may be forced to do more paging itself, to and from the swap space. Normally, DABACON paging is more efficient than the computer paging as DABACON has extra knowledge on what has been accessed. Thus if the computer is having to do a lot of paging to swap, then normally it is best to reduce the DABACON buffer size. It must be emphasised that there are no firm rules which determine the best buffer size for a particular module/computer. Each machine will have an optimum combination of main memory size, disk I/O capacity, DABACON Buffer size etc., which will probably vary throughout the life of the project. PDMS System Managers will learn by experience the best buffer sizes for general usage on their computers. The default buffer size is 5,120,000 words (20 Mbyte) for all modules and this will often prove to be a suitable compromise. On an installation where the computer has plenty of spare memory, no paging, but overloaded disk channels, it may be useful to increase the buffer size. A typical example in which the use of a larger buffer may be justified is when doing a clash check.


5 Setting Up a New Project

5.1 Summary

A PDMS project is identified by a three-letter project code. In the following example the code ABC is used. The stages in setting up a project are as follows: 1. Create the project directory and sub-directories. 2. Set the environment variables for the project. 3. Run the scripts and macros supplied with the product. 4. Enter PDMS as SYSTEM, and start to create Users, Teams,

Databases and MDBs in the project. Note that before this stage can be started, you should plan the requirements of your project, as described in Chapter 6, Designing a Project.

5.2 Creating the Project Directory Structure

To create a new project ABC, proceed as follows: 1. In Windows Explorer, go to the directory where you want to create

the project. For example: users\pdmsproj

Within this, you may like to create a directory for each project, for example, abc, but this is not essential.

2. Create four directories below the Project directory (or below abc): abc000 This directory will hold all the database files in

the project. abcmac To hold inter-DB connection macros. abcpic To hold DRAFT picture files. abciso To hold all ISODRAFT project-related data.

3. Now create the sub-directories needed by ISODRAFT in the abciso directory: LIS To hold detail lists.


Setting Up a New Project

STD To hold option files for standard isometrics. SYS To hold option files for system isometrics. UND To hold underlay files.

4. Change the access rights for the working directories to allow all PDMS project users Read/Write access: Select each directory in turn (abc000, abciso, abcmac and abcpic). For each one, click the right mouse button and select Properties. Select the Security tab and check that the permissions are set correctly.

5.3 Setting the Environment Variables

Set the environment variables pointing to the directories you have just created. The variables would normally be set in the evars.bat file. Select Start > Settings > Control Panel > System, and select the Environment tab.

ABC000 pathnameabc000 ABCISO pathnameabciso ABCMAC pathnameabcmac ABCPIC pathnameabcpic



5.4 Creating a Project

Several macros and utilities are provided in the PDMSEXE directory to create a new project. When you install PDMS, a shortcut, Make PDMS Project, is created under the Start menu. To create a new project, make sure that you have created the project directories and set the environment variables as described above, then proceed as follows: 1. Click on the Make PDMS Project shortcut. This starts the PDMS Project

Creator utility, which runs the file make.bat. 2. Enter the project name (the three-letter project code); for example,

abc. You will see an asterisk * command prompt. 3. Run the utility makemac.mac by typing:

$m%PDMSEXE%/makemac.mac You will a message: Creating module definitions referencing %PDMSEXE%

4. Then type: finish

to exit from the PDMS Project Creator. You can now enter PDMS by clicking on the Start PDMS shortcut, and selecting your new project.

5.4.1 The make Utility

The make utility runs the makemac.mac macro, which: • Creates the virgin databases. • Sets up the PDMS module definitions by running modmac.mac. For

more information about module definition, see Chapter 14, Modules. • Sets the font directory. For more information, see Chapter 12. Note that MONITOR and ADMIN are already defined in the supplied product, and also that a utility file named delmac.mac is supplied, which deletes all module definitions from the project.



5.5 The Completed Project

Project ABC has now been created. The directory ABC000 should contain a SYSTEM database, a backup SYSTEM database, a COMMS database, a MISC database. The System DB will have been configured to handle the number of simultaneous users indicated. A single team called Master will also have been created, with a single user called SYSTEM whose password is XXXXXX. Information about all modules will have been stored. You can now enter PDMS as user SYSTEM and access the project. However, before you start creating the ADMIN elements of Users, Teams, Databases and MDBs, you need to plan how the Project will be structured. An example is described in Chapter 6, Designing a Project.


6 Designing a Project

This chapter gives an example of how a simple project could be designed. It describes what databases will be required, and what users and teams. It also describes how the databases should be added to the MDBs.

Databases The project will contain the following databases:

A pipework catalogue. A steelwork catalogue. Four Design databases, for pipework and steelwork in two areas of the plant, North and South. A Draft database. An Isodraft database. A Properties database.

Teams and Users This will mean creating the following teams and users: Team User/Password Owning the database(s) Type

CATA CATA/CATA CATA/PIPE CATA/STEEL

CATA

PIPE-N PIPE-N/PIPE-N PIPE-N/PIPE-N DESI

PIPE-S PIPE-S/PIPE-S PIPE-S/PIPE-S DESI

STEELN STEELN/STEELN STEELN/STEELN DESI

STEELS STEELS/STEELS STEELS/STEELS DESI

DRAFT DRAFT/DRAFT DRAFT/DRAFT PADD

ISO ISO/ISO

ADMIN ADMIN/ADMIN ADMIN/DICT

ADMIN/PROP

DICT

PROP

In addition, the following teams and users will be needed for the administrative functions within the constructor modules.


Designing a Project

For example, access to the DRAFT Administrator application is only available to members of the DRAFTADMIN team.

Team User/Password PARAGONADMIN PARADM/PARADM

DESADMIN DESADM/DESADM

DRAFTADMIN DRAADM/DRAADM

ISOADMIN ISOADM/ISOADM

MDBs

User CATA CATA will have write access to the databases CATA/PIPE and CATA/STEEL. CATA will not need access to any other databases, so the list of databases in the MDB CATA will look like this:

CATA/PIPE CATA/STEEL

User PIPE-N PIPE-N will have write access to the database PIPE-N/PIPE-N. This user will need read access to the following databases:

The pipework Catalogue CATA/PIPE The steelwork Design database STEELN/STEELN, for clash checking.

The list of databases in the MDB PIPE-N will look like this: PIPE-N/PIPE-N CATA/PIPE STEELN/STEELN

Users PIPE-S, STEELN, STEELS These users will have MDBs similar to PIPE-N, with corresponding access rights to the appropriate Design databases. User DRAFT User DRAFT will have write access to the DRAFT/DRAFT database. This user will need read access to all the Design databases and Catalogue databases, and so the list of databases in the MDB DRAFT will look like this:

DRAFT/DRAFT PIPE-N/PIPE-N PIPE-S/PIPE-S


Designing a Project

STEELN/STEELN STEELS/STEELS CATA/PIPE CATA/STEEL

User ISO User ISO will need read access to all the Design databases and Catalogue databases, and so the list of databases in the MDB ISO will look like this:

PIPE-N/PIPE-N PIPE-S/PIPE-S CATA/PIPE CATA/STEEL

The options under Install on the main ADMIN menu are used when you are setting up a new project, and you want to make use of the databases supplied in the sample project. For more information, see Section 7.6.4, Including and Copying Foreign Databases.


Designing a Project


7 Creating the Main ADMIN Elements

This chapter describes how to create and modify the main administration elements: TEAMs, USERs, DBs and MDBs. The examples are based on the project described in Chapter 6, Designing a Project. These are the elements you must have in any PDMS project. Other element types which are used in Data Access Control (DAC) are described in Chapter 10, and the Stamp element, which is used to stamp database sessions, is described in Chapter 9.

7.1 Starting Up ADMIN

When the project has been set up as described in Chapter 5, you can start PDMS as SYSTEM/XXXXXX, giving the code of the new project. Enter ADMIN by selecting Admin from the Modules option list. You will see the main ADMIN menu bar across the top of the window:

The options on this menu bar provide access to all PDMS project administration tools. The options under the first five menu headings (Admin, Display, Query, Settings and Utilities) are similar to the options on other GUI modules. The other options are specific to ADMIN. You will also see the ADMIN Elements form, which allows you to create, copy, modify and delete the ADMIN elements. This form is similar to the Members list in other modules: it displays a list of all the elements of the type shown on the Elements drop-down list. This form has different states, depending on which element type is being displayed. The buttons at the bottom of the form (Create, Copy, Modify, Delete, etc.) will allow you to handle elements of the appropriate type. Some buttons will be inactive for some element types.


Creating the Main ADMIN Elements

Note: The first time you enter ADMIN, you should change the System

Administrator's userid and/or password. This is very important for the security of a real project, but note that it has not been done in the examples, and the Free user is still shown as SYSTEM/XXXXXX.



7.2 Summary

Once you have decided on the ADMIN elements you need, the recommended sequence is as follows: 1. Create Teams. 2. Create DBs. 3. Create Users and add them to Teams. 4. Create MDBs and add databases to them. The rest of this chapter follows this sequence, and then describes some other features which you will find useful when you are creating ADMIN elements.

7.3 The Admin Elements Form

This is the main form in PDMS ADMIN. It enables you to create, copy, modify and delete the Admin elements such as Users, Teams, Databases, MDBs and Stamps, and to add Users to Teams and Databases to MDBs. You can also set attributes for these elements. The form has different states, corresponding to the different types of element. The element type is set using the Element option button at the top of the form. The scrolling list on the form will display the elements of the current type, and the gadgets available will change according to the type of element. You can use the left and right arrow buttons to move one place up or down the list respectively. You can also navigate to an element by selecting it in the list.

7.3.1 Querying Attributes

If you click on an element in the Admin Elements form with the right-hand mouse button, you will see a menu with the option Query Current Element. If you select this option using the left-hand mouse button, a Query Results form will be displayed, showing the results of the query.



7.3.2 Querying the Project

The other option on the menu displayed when you click the right-hand mouse button in the Admin Elements form is just Query. The submenu to the right of this option allows you to query the Project: the options are the same as those under Query > Project on the main menu, that is, User Status, Users, Teams, Databases, Database Sessions, MDBs and Stamps.

7.3.3 Configuring the Admin Elements Form

The options under Settings > Display Mode allow you to customise the information about elements which is displayed on the Admin Elements and other ADMIN forms. Select Names or Descriptions, according to which you want to see. The other options are: Resize Admin Elements form This option displays the Resize Admin Elements form. Use the arrows to increase or decrease the size of the Admin Elements form.

Setup Admin Elements form This option displays the Level of Detail ... form, where you can specify which columns are shown on the Admin Elements form.



Manage User Config file These options allow you to save your settings of the other options to a file, load a saved file, reset the options to their supplied defaults, or delete a saved file.

7.4 Sorting and Filtering The Sort by and Filter gadgets under the scrolling list on the Admin Elements form (and on several other forms which display lists of elements) enable you to sort and filter the contents of the list, which may be useful when you have a lot of elements displayed. These gadgets appear on many forms which contain a list of elements. When a new element group is selected, the Sort By option list is initialised to contain a set of options applicable to that element type.



The Filter gadget allows you to restrict the elements shown in the list to names containing given characters. By default, the list will show all elements of the given type, as indicated by the * in the Filter textbox. The wildcards you can use are:

* Any number of any characters ? Single character

The filter is reset to contain * whenever a new element group is displayed. The filter for each element type is remembered and re-used when the element type is next displayed on the Admin Elements form. The filter always operates on the element name.

7.5 Teams and Users

You can create Teams and Users in any order. If you create the Teams first, you can add Users to them as they are created using the Create User form. Alternatively you can create the Users first and add them to Teams using the Create Team form. In the following example, the Teams are created first.

7.5.1 Creating Teams

To create a Team, set the Element option button on the Admin Elements form to Team, and press Create. The Create Team form will be displayed.



To create a Team, enter a Name and, optionally, a Description. Press Apply, and the Team will be created. On the left of the form there is a list of the existing users in the project. If users have already been created, you can add a user to the team by selecting the element in the left-hand list, and selecting the right arrow button. The user will be added to the team, and the user’s name will appear in the right-hand list. Note: You can also add users to teams on the Create User form. Note the Sort and Filter gadgets: see Section 7.4, Sorting and Filtering, for more information.

7.5.2 Creating Users

To create a user, set the Element option button on the Admin Elements form to User, and press Create. The Create User form will be displayed.



Enter a Name and Password, and set the Security option button to Free if you want to create a FREE user. You can enter a Description if you wish. Press Create, and the user will be added to the Membership list. You can add the user to existing teams using the User Membership scrolling lists. All the teams in the project are shown in the Project Teams list. The Membership list shows the members of the team selected in the Project Teams list. You add the member you are creating to a team by selecting the team and pressing the right-hand arrow. A member can be removed from a team by selecting the user in the Membership list and pressing the left-hand button. Notes: You can also add users to teams on the Create Team form. The User Access Control Rights (ACRs) area of the form allows you to

set ACRs for the user, as described in Chapter 10.



7.5.3 Modifying Attributes of Users and Teams

The attributes of Users and Teams can be modified using forms very similar to the Create forms. To display the Modify forms, select the element you want to change in the Admin Elements form and then either: press Modify on the Admin Elements form, which will display the Modify form,

or select Modify from the Create/Modify option button on the Create form, if it is displayed, and the mode will change to Modify. For Users you can change:

Name Password Security Description Team Membership ACRs

For Teams you can change: Name Description Membership

7.5.4 Copying Users and Teams

Teams and Users can be copied by selecting the required type of element from the Element option button on the Admin Elements form, selecting the element you want to copy from the scrolling list, and then selecting the Copy button. The appropriate Copy form will be displayed. Users The Copy User form allows you to give a Name (To User), Password, Security and Description for the new element. Note that the new user will automatically be a member of the same teams as the original user. Teams The Copy Team form allows you to give a Name (To Team) and Description for the new element. If you switch on the Include Users button, all the members of the original team will be members of the new team. Copies of all the databases owned by the team will also be made and will belong to the new team.



7.5.5 Deleting Teams and Users

Teams and users can be deleted by selecting the element from the scrolling list on the Admin Elements form and then pressing Delete. If you try to delete a team which owns databases, you will be prompted to delete the databases before you can delete the team: the Admin Elements form will change to Database mode, listing the owned databases, to allow you to do this.

7.6 Databases

7.6.1 Creating Databases

To create a database, set the Element option button on the Admin Elements form to Databases & Extracts, and press Create. You will see a small form prompting you to select whether you want to create a normal Master DB or An Extract of a DB:

When you select Master DB, the Create Database form will be displayed.



The database name is shown at the top of the form. Database names are in the format:

TeamName/DatabaseName where TeamName is the name of the team which owns the database, and which therefore has write access to it. If there is no current team, the database name will be shown as unset/unset. If there is a current team, the team name will be shown as the first part of the database name.



The Owning Team is selected from the scrollable list. Note the Sort by and Filter option buttons: see Section 7.4, Sorting and Filtering, for more information. Enter the Database Name in the Name textbox. Enter an optional Description. Select the Database Type from the option button. Select the Access Mode: if you choose Multiwrite, you should also select the Claim Mode from the next option button. For more information about Multiwrite Databases, see Chapter 8. You can specify that the database will be Controlled; that is, access is controlled by an external system. For more information, see Section 3.10. The Area number, DB number and File number are normally set by the system, as shown by the word System entered in the text boxes. It may sometimes be necessary to set them manually.

The Area number is used if you need to store databases in a different directory. See Section 11.9, Distributed Databases, for more information. You can reset this attribute by pressing the System button to the right of the text box. The DB number is used internally by PDMS to identify the database. When a database is copied or an extract is made, the copy or extract keeps the same DB number as its parent. You cannot have more than one database with the same DB number in the same MDB (unless the database is a Working Extract, see Section 8.2.1. The DB number for a user database must be in the range 1 - 6999: the higher numbers are reserved for AVEVA Solutions use. You can reset this attribute by pressing the System button to the right of the text box. The File number is used in generating the filename of the database. For example, a database in project abc with file number 12 will be stored in the file named abc012. The File Number text gadget will only accept values in the range of 1-8192. This value entered must be unique within the project. If the value is set to System (using the button next to the text box) then the file number will be set to 0. This is recommended, particularly if you are gong to use extracts, as it will ensure that filenames are consistent within an extract family. In modify mode, the text box is inactive: you can only change the file number to 0 by pressing the System button.

Press Apply, and the database will be created.



7.6.2 Modifying Database Attributes

The attributes of databases can be modified using a form very similar to the Create form. To display the Modify form, select the element you want to change in the Admin Elements form and then either: • press Modify on the Admin Elements form, which will display the

Modify form, or

• select Modify from the Create/Modify option button on the Create form, if it is displayed, and the mode will change to Modify.

You can change the Name, Description, Access Mode and Area Number of a database, and whether or not it is a Controlled database. The Type, DB number and File number cannot be changed. Note: If you try to change a database name to a name that already

exists, you will be prompted to confirm that you want to overwrite the database.

7.6.3 Copying Databases

Copied databases can be used for: • Copying a template project. • Merging projects. • Copying included databases before archiving. Note: If you want several users to be able to work on copies of the same

data, it may be more appropriate to use Extracts. See Section 8.2. Databases can be copied by selecting Database from the Element option button on the Admin Elements form, selecting the element you want to copy from the scrolling list, and then pressing the Copy button. The Copy Database form will be displayed.



On the form, you can specify the owning team by selecting one from the list of all the teams in the project. You can give the copy a Name, Description and Area Number. Note that you cannot change the database number of the copied database. This will be same as the original. You cannot have more than one database with the same database number in the same MDB. Note: To avoid the risk of database corruption, all copying of databases

(i.e. the files inside the Project directory) must be done from the ADMIN module and not by using operating system utilities or commands.

Copied databases can be changed or deleted.

7.6.4 Including and Copying Foreign Databases

You can copy databases from other projects. Databases can also be shared between many projects, which saves disk space and eliminates errors which could be caused by copying. Catalogue databases are often shared in this way.



Databases included from a second project are also known as foreign databases. The second project must be available: that is, you must be able to read from the second project directory, and have the environment variables for the second project set. When you create a project that is going to share databases from other projects, there are two important considerations: • Teams must exist for all databases that are to be shared. • Databases in the source project that will be shared must not be

given a database number that will clash with a database number that already exists in the destination project.

Note that foreign databases are marked with * in the database list. To include a foreign database, set the Element option gadget on the Admin Elements form to Database, and press the Include DB button. The Include Foreign Db form will be displayed.

Foreign Projects lists the other projects available. Access Project as. You must enter a Username and Password for a Free User in the Foreign Project. Foreign dbs lists the databases in the foreign project.

Select the databases you require and press Apply. You will be prompted to create the owning team, if it does not already exist in the current Project. You cannot include a database which has the same teamid/dbname as an existing database in the current project. You can exclude foreign databases by pressing the Exclude DB button on the Admin Element form. The Exclude Db form will be displayed To copy a foreign database, set the Element option gadget on the Admin Elements form to Database, and press the Copy Foreign DB button. The Copy Foreign Db form will be displayed.

Foreign Projects lists the other projects available. Access Project as. You must enter a Username and Password for a Free User in the Foreign Project. Foreign dbs lists the databases in the foreign project. Target Database name is set as follows: pick the team which will own the database from the list, and enter the database name.

Press Apply. You cannot include a database which has the same teamid/dbname as an existing database in the current project.



7.6.5 Copying and Including from the Sample Project

You can include or copy databases from the sample projects (SAM and MAS) if you have got these projects available and their project variables are set, using the options under Install on the main men These options are as follows:

Sample Project >Foreign Master DBs This option sets pointers to all the databases in the MAS project. Local Master DBs This option copies all the databases in the MAS project to the local directory.

Foreign Master DBs>

The options allow you to set pointers to individual databases in the MAS project.

Local Master DBs>

The options allow you to copy individual databases in the MAS project to the local directory.

7.6.6 Deleting Databases

Databases can be deleted by selecting the element from the scrolling list on the Admin Elements form and then pressing Delete. Note: To avoid the risk of database corruption, all deletion of databases

(i.e. the files inside the Project directory) must be done from ADMIN and not by using operating system utilities or commands.

7.7 Database Sets

Database Sets are sets of databases that can be handled as a single unit. For example, a database set can be added to or removed from an MDB, or DICE-checked DB sets can contain other DB sets. To create a DB Set, set the Element option button on the ADMIN Elements form to DB Sets, and press Create. The Create DB Set form will be displayed.



The Non Members DB Sets list shows all the DB Sets which have not already been added to the current set. The Non Members DBs list shows all the databases which have not already been added to the current set. The Members (Ordered) list shows all the databases that are part of the current DB set. To add a DB Set or DB to the Members (Ordered) list: • In the Members (Ordered) list, highlight the element either

immediately after or just before where you want to add the new DB Set or DB.

• Use the Add Elements gadget above the Members (Ordered) list to show whether the new DB Set or DB is to be added After or Before the highlighted element.

• Select a DB Set that you want to add from the Non Members DB Sets list, or a DB from the Non Members DBs list.

• Press the appropriate Add button. Note that you cannot have more than one database with the same database number in a set.



7.8 Multiple Databases (MDBs)

7.8.1 Creating MDBs

To create an MDB, set the Element option button on the ADMIN Elements form to MDBs, and press Create. The Create Multiple Database form will be displayed.

The Create Multiple Database form allows you to give the MDB a Name and a Description.



The scrolling lists are used to define the databases in the MDB, and whether they are current or deferred. An MDB may contain up to 1000 databases. However, only 300 of these (known as the current databases) can be accessed at any one time. The other databases are deferred. Databases can be transferred between current and deferred status at any time, so that a user can replace a current database by a non-current one to access a particular part of the design. The Project Databases list shows all the databases in the project which are not in the MDB. The arrow buttons are used to add and remove databases from the MDB, either as current or deferred, and to change a database between the current and deferred lists. The Insert option button is used to position the databases in a specified order in the list of current databases. The order is important: see Section 3.8, Multiple Databases. Notes: Two databases will have the same DBNO if one has been created

as a copy or as an extract. An MDB can only contain one database with a given DBNO.

There can be a performance issue with large lists of databases. However this can be improved using the Rebuild Lists On/Off toggle. If this toggle is switched Off then the lists are not rebuilt each time a database is moved; only when using the Apply or the Now button. The default, however, is On. The picking order of databases is relevant, where databases will be added or exchanged in accordance with the pick order.

7.8.2 Adding DB Sets

If you have created a DB Set, you can add it to an MDB in one operation. When the Create MDB form is displayed, move the cursor into one of the scrolling list areas, and press the right-hand mouse button. A pop-up menu will appear: choose Select a Set of DBs and select the DB Set you want from the small form listing DB Sets available. Then add the Set using the arrow button as normal.

7.8.3 Modifying MDBs

The attributes of MDBs can be modified using a form very similar to the Create form. To display the Modify form, select the element you want to change in the Admin Elements form and then either:



• press Modify on the Admin Elements form, which will display the Modify form, or

• select Modify from the Create/Modify option button on the Create form, if it is displayed, and the mode will change to Modify.

You can change the Name, Description, the databases in the MDB and which databases are current or deferred.




8 Multiwrite Databases and Extracts

The simplest way of creating a multiwrite database is to specify that the database is MULTIWRITE (rather than UPDATE) when you create it. Simple multiwrite databases are described in Section 8.1. However, much more sophisticated multiwrite facilities are available using database extracts. You should read Section 8.1 in any case, as it applies to all multiwrite databases, and then refer to Section 8.2 for more information about extracts.

8.1 Simple MULTIWRITE Databases

Multiwrite databases allow more than one user to write to the same database. Elements in multiwrite databases must be claimed when they are modified so that no other user can change them at the same time. When you create a multiwrite database, you must set its claim mode: • If the claim mode is explicit, users must explicitly claim any element

they wish to change before the modification starts. • If the claim mode is implicit, an element will automatically be

claimed when it is modified. If a user tries to claim an element that has already been claimed, the second claim will fail. The disadvantage of implicit mode is that users may spend some time defining a change, for example, filling in a form, and then not be able to apply the form if the element has been claimed by someone else. In a simple multiwrite database, all claimed elements are released when you change modules. Elements can be released at any other time, providing they have not been modified since the last SAVEWORK. You can only claim primary elements. See the appropriate Reference Manual for each PDMS module for information about primary elements, and what happens in special cases.


Multiwrite Databases and Extracts

8.2 Extracts

An extract is created from an existing database. Extracts can only be created from multiwrite databases, and all extracts are themselves multiwrite. You can create Extract DBs from any type of database that can be multiwrite, that is DESI, PADD, CATA and ISOD databases. • You cannot create extracts from foreign DBs. • You cannot create extracts from copy DBs. An extract can be worked on by one user at the same time as another user is working on the master or another extract. When a user works on the extract, elements are claimed to the extract in a similar way to simple multiwrite databases, so no other user can work on them. When an extract user does a SAVEWORK, the changed data will be saved to the extract. The unchanged data will still be read via pointers back to the master DB. When appropriate, the changes made to the extract can be issued, that is, written back to the parent database, or aborted (dropped), which means they will be deleted from the extract. Also, the extract can be refreshed, that is, updated with changes made to the parent only (which itself may actually have been made in another extract). Alternatively, an extract can be fully refreshed, that is, updated with changes made from all its extract ancestors.

8.2.1 Types of Extracts

Standard extracts are used in a similar way to normal multiwrite databases. In addition, you will normally create Working Extracts for individual users: one working extract can be created from each database for each user. Working extracts do not need to be added to MDBs. When a user selects an MDB that includes databases for which that user has working extracts, data is actually written to the working extract. You cannot create other extracts from working extracts: they are always at the bottom of the extract tree. They are designed to be the databases which users actually write to; higher levels will normally be used for tasks such as checking and approval, probably in conjunction with Data Access Control. Variant Extracts allow different design solutions to be tried out without the need to claim elements to the extract: when one solution is selected, the data in the chosen variant extract can be issued back to the master database.



8.2.2 Advantages

The advantages of extracts compared to simple multiwrite databases are: • Claimed elements are not released when you change module or exit

from PDMS. • You can save your changes to the extract, without updating the

owning database until you are ready. • You can issue or drop partial changes. Extracts can be used to control approval and issuing of work. For example, changes can be issued when given criteria are met. Other users can then read the approved data rather than the working data. Using Data Access Control to control workflow is described in Chapter 10.

8.3 Extract Families

The original database is known as the Master database. The Master database is the parent of the first level of extracts. If a more complex hierarchy of extracts is created, the lower level extracts will have parent extracts which are not the master. A Master DB may have up to 191 extract DBs. You can create an extract from another extract, forming a hierarchy of extracts. All the extracts derived from the same master are described as an Extract Family. The extracts immediately below an extract are known as Extract Children. If a hierarchy of extracts is created, the parent extracts for an extract, up to and including the Master DB, are known collectively as the Extract Ancestors.



The following diagram illustrates an example of an extract family hierarchy:

In this example:

PIPE is the Master and the Parent of PIPE_X1

PIPE_X1 is a Child of PIPE and the Parent of PIPE_X10

PIPE_X10 is a Child of PIPE_X1

The Children of PIPE are PIPE_X1 and PIPE_X2. PIPE and PIPE_X1 are the Ancestors of PIPE_X10.

Write access to extracts is controlled in the same way as any other database: • The user must be a member of the team owning the extract. Extracts

in the same family can be owned by the same team or by different teams.

• The user must select an MDB containing the extract. • Data Access Control can be applied. Extract families enable several users' work to be combined into another higher-level extract, which can then be approved before updating the master.


aveva

Insert the Diagram


8.4 Using Extracts

This section describes the concepts of how extracts are used in the constructor modules. For details of the commands, see the Command Reference Manuals for the constructor modules. For details of the forms and menus, see the on-line help for the constructor modules.

8.4.1 Claiming

When a user working on an extract database creates or modifies an element, it is claimed out to the extract. This is known as an extract claim. Once an element is claimed to an extract, user claims are made in the same way as in any other multiwrite database. An element must be claimed to an extract before a user claim can be made (in implicit mode, this happens automatically). Only primary elements can be claimed. • If an element is claimed to an extract, only users with write access to

the extract will be able to make a user claim and start work on the element.

• Once a user has made a user claim, no other users will be able to work on the elements until they are released, as in a normal multiwrite database.

• If a user releases an element, it will remain claimed to the extract until the extract claim is released.

Note: Changes made in the extract are written back to the parent database, without the normal PDMS requirement for the parent database to be in the current MDB.

The EXTRACT CLAIM command works up through the extract levels, claiming as necessary: the user does not need to claim each level of extract separately. For example, consider the following three-level extract:

AsBuilt Extract

↓

Approved Extract

↓

Working Extract

If the current claim is on the AsBuilt extract, an element claim is propagated down through the Approved extract to the Working extract;



that is, the element is claimed from the AsBuilt to the Approved, and then from the Approved to the Working extract. The sequence is:

Is element already claimed to Working? If Yes: Do nothing. If No: Is element claimed to Approved extract?

If No: claim from AsBuilt to Approved, then claim from Approved to Working. If Yes: claim from Approved to Working.

The extract claim may fail for similar reasons to a user claim failure; that is: • Another user/extract has the item claimed. • The element is modified in a later version, so that a refresh is needed

first. The implicit/explicit claim modes, as determined by the DB setting, apply to both user and extract claims. For extract claims, the claim mode is tested for each extract level in the hierarchy from which the claim is made. If the claim mode on an extract is explicit, then implicit claims which require a claim from that extract will fail. Thus if, in the preceding example, the Working and Approved DBs are set to implicit claim mode, an implicit claim will be attempted as soon as a user modifies any unclaimed element. The following sequence applies: 1. A user claim is attempted from the Working DB. 2. If the user claim fails because the element has not been claimed in

the Working DB, then an extract claim is attempted from the Approved DB to the Working DB. Since the Approved DB is also in implicit mode, this is attempted automatically.

3. If the extract claim fails because the element has not been claimed in the Approved DB, then an extract claim is attempted from the AsBuilt (Master) DB to the Approved DB. Since the AsBuilt DB is not set to implicit claim mode, the operation will fail.

In the standard case, there are always two parts to a claim or release; for example, a claim 'from' the parent extract 'to' its child extract. Every time a claim (or release) is made, the underlying DB is accessed. To minimise such access, and thus speed up the process, it is best to claim as many elements as possible in a single operation. A convenient way of doing this is to build a PDMS 'collection' and then claim the elements from there; for example:

EXTRACT CLAIM ALL FROM !COLLECT



8.4.2 Refreshing

This option updates an extract with changes made. The update can be a refresh from the parent database only (which itself may be an extract). Alternatively, if there is a hierarchy of extracts, a full refresh can be used instead, to update an extract with changes from all its ancestors. Refreshing operates on a whole database: partial operations are not possible. If changes have been made to the data in an extract, the changes will not be visible in lower extracts until these extracts are refreshed. Note the difference between GETWORK, REFRESH and FULLREFRESH: • GETWORK will get changes made to databases in the current MDB. • REFRESH will get changes made to the parent extract only of an

extract in the MDB. • FULLREFRESH will get changes made to all the extract ancestors of an

extract in the MDB. Note: Full refresh updates your view of the data with changes made at

higher levels in the extract tree. However, when you do a savework, users of extracts which are children of your extract will not be able to see your changes until they also do a refresh.

8.4.3 Flushing

When an extract user makes changes and saves them, they are stored in the extract. The changes can then be flushed, which means that they will be made available to the parent extract. The local changes are copied to the parent extract, but the elements are not released. Users who have access to the parent database can now see the changes, but they still cannot make changes of their own to the elements. A single element, or a database, or a collection of elements can be flushed. If changes need to be made available in the master database, it will be necessary to flush the changes up through each level of extracts. Users accessing extracts in other branches of the extract tree will need to refresh their views of the data to see the changes.



The following diagram illustrates the sequence of commands that need to be given so that a user working on extract B2 will be able to see the changes made by a user working on extract A2.

A flush can, optionally, do an implied refresh. It is more efficient to do this.

2 FLUSH

3 REFRESH

A2

B1 A1

4 REFRESH 1

FLUSH

B2

MASTER

8.4.4 Release

The user can only release an extract claim if no changes have been made, or if all the changes have been flushed. Other users who have write access to the parent database can now make changes to the elements. They will need to GETWORK before the changes are visible.

8.4.5 Issue

The local changes are copied to the parent extract, and the elements are released. Users who have write access to the parent database can now make changes to the elements.

8.4.6 Drop

The local changes are abandoned. There will be no change to the parent extract. The extract will return to the state before the changes were made, even though the user has done a SAVEWORK.



8.4.7 Partial operations

Users can carry out partial issues, flushes, drops and releases on specified parts of the database. Setting up an Extract Hierarchy Before you start creating extracts and working extracts, you should have a clear plan of how they will be used. You should maintain diagrams of the basic master extract–working extract database organisation. These help when designing flush and release procedures, and defining MDBs.

Note: The databases shown are all part of the same extract family, and

so they will all have the same database number, for example 200. See Section 10.8 for an example of how you might use extracts and working extracts with data access control (DAC) to control work flow.

PIPE/REVIEW

First level extract

Second level extract

Working extract for UserC

Working extract for UserB

Working extract for UserA

PIPE/CURRENT

PIPE/PIPE



8.5 Creating Extracts

Before you create an extract, you must have created the master database, which must be multiwrite. Note: An extract can be created only at a node or at the root of an

extract family. That is, you can create an extract at the bottom of an extract tree or you can create a new master for the extract family, but you cannot insert an extract between different levels.

Set the Elements drop-down list on the Admin Element form to Databases & Extracts and press Create. On the small form displayed, select Extract. The Create Extract form will be displayed.



The Extract team_id/dbname is shown at the top of the form. Initially this will show the name of the team which owns the database selected in the Admin elements list, followed by unset for the dbname until you actually fill in a name for the new extract.



The extract will be created from the database selected in the Select Database for Extract list. This list shows all the databases (including any existing extracts) in the project. Note: Extracts are marked with an X on this form, and in the Admin

Elements form. Variants are marked with a V. Check that the Owning Team is set to PIPE. Note that the team owning the extract can be different from the team owning the parent extract. Give the extract a Name and optionally a Description. Leave the other options at their default values (for more information, see the following subsections) and press Apply. Note: Extracts cannot be copied in the way that DBs are copied. An

extract variant will have to be created instead: see Section 8.7.

8.5.1 Extract Naming and Numbering

Database Numbers. An extract has the same database number as the master database. This means that no MDB or DB Set can contain more than one database in the same extract family (but see Working Extracts, Section 8.2.1). Extract Numbers. Each extract, including the master, has an extract number which is unique in the extract family. When an extract is made, the master database itself becomes an extract, and the master extract will always have extract number 1. By default, each extract will have an extract number allocated sequentially as it is created. You can specify a particular extract number on the Create Extract form. • Before you start creating extracts, you should work out an extract

numbering system, and set the extract numbers explicitly when the extracts are created.

Each extract DB is stored in a separate file. The filename of an extract is of the form: prjdddd_eeee where: prj is the project code dddd is the database number eeee is the extract number For example, extracts of a database with filename xyz0099 will have filenames xyz0099_0001, xyz0099_0002, etc. Extract numbers must be between 1 and 8191 inclusive, for each extract family.



8.5.2 Deleting an Extract

An extract may be deleted in the same way as other databases. You cannot delete an extract if the extract owns other extracts.

8.5.3 Extracts and Foreign Projects

You can include extracts from foreign projects, but not under the following conditions: • You cannot include an extract unless you include its parent first. This

implies that you must include the master extract first, and then work down the extract tree.

• You cannot exclude an extract which has children included. This means you must start at the bottom of the included extract tree, and work up.

8.5.4 Adding Extracts to MDBs

Extract DBs may be included in MDBs, as for Master DBs. No two extracts with the same DB number may be included in the same MDB (like Copy DBs). For example, an MDB /AREAEX1 might consist of two Design DBs, two Catalogue DBs, and a Dictionary DB, thus: STRUCA/AREAEX1 PIPEA/AREAEX1 CATA/CATA1 CATA/CATA2 DICT/DICT1

When the extract DBs are opened in the modules, the parent extracts will also be opened in Read mode. This is done automatically by the system, so that it is not necessary for the parent extracts to form part of the MDB.

8.6 Working Extracts

8.6.1 Creating Working Extracts

Working extracts can be created from any multiwrite database, including standard and variant extracts. To create a working extract, set the Elements option on the Admin Elements form to Working Extracts and press Create. The Create Working Extracts form will be displayed.



Select the Database to Create Working Extracts From in the top list. From the User List, select the users who will have working extracts of this database. Note that you can select several users if you want them to have working extracts of the same database. You can give the extract a Description. Note that names of working extracts are generated automatically. The claim mode, and whether or not the database is controlled, are the same as for normal databases; see Section 3.10. You can also specify that the working extract is a variant extract; see Section 8.7.



8.6.2 Using Working Extracts

Working extracts are largely invisible to users, although users will need to be aware that they are using extracts, and that they will need to use the normal extract controls (flushing, releasing, etc.). If you are working with extracts, the normal way of working is to create working extracts for the users who are actually creating data. Intermediate levels of extract will normally be used for checking, approval etc. Working extracts are always 'implicit', so there is no need to use the CLAIM/UNCLAIM commands (which have no real meaning when using working extracts). Similarly, Q CLAIMLIST has little meaning, other than to indicate what the user is currently working on. A user should always use Q CLAIMLIST EXTRACT when using working extracts, to check what is claimed to the working extract and, hence, what is truly claimed to that user.

It is strongly recommended that users should work either totally with working extracts or totally without.

8.6.3 Issuing from Working Extracts

When you issue data from a working extract, it will be issued to the database from which the working extract has been created. In order to issue data from an extract which has working extracts to an extract further up the extract tree, there must be a user who does not have a working extract: see the following diagram.



Note that you cannot issue changes from working extracts without first releasing the user claim. Working extracts are never included in MDBs, but are substituted for their parent extract automatically as a user selects the MDB. For example, if the parent extract is aaaa/bbb, then when a user with the working extract uses an MDB containing aaaa/bbb, the working extract will be used automatically instead of aaaa/bbb. Although working extracts do have names, it is not necessary to know it when working in DESIGN. When in ADMIN, the working extract name is applicable for commands such as CHECK, EXPUNGE and RECONFIG.

Extract 1

Extract 2

Working extract of 2 for USERA

USERA and USERB will issue to Extract 2.

You must have another user with no working extract to issue from Extract 2 to Extract 1.

Working extract of 2 for USERB



8.6.4 Extract Control

If you select Data > Extract Database Control you will see the Extract Database Control form.

The left-hand list shows all the extract databases in the project (including master databases): you can use the Sort Databases options to sort the list Alphabetically or to show the extract Hierarchy. The right-hand list shows information about the database selected in the left-hand list. If you switch on Show Extract Elements at the top of the form, the list will also show the elements extracted to this DB. The Extract DB Operations buttons at the bottom left of the form allow you to flush, issue or abort all changes to the selected DB. The Get All Changes button at the bottom right of the form allows you to refresh an extract DB. Use From parent only to refresh an extract DB with changes from its parent extract only, or use From all ancestors to fully refresh an extract DB with changes made from all its extract ancestors. Using From all ancestors will consequently update the intermediate ancestors.



8.7 Variant Extracts

Both standard and working extracts can be variant extracts. Variants are a special type of extracts in which elements are not claimed from the parent. They are designed to allow users to try out different designs, which then may or may not be written back to the master. When variants are used, all changes are merged together on issue. Changes are handled at attribute level, so that different users can change different attributes on the same element and then merge their changes. No locking is applied to a variant extract, and any locks applied to other extracts are ignored. This allows many users to modify the same element in a given session, but has the disadvantage that any conflicts will not be found until the changes are issued. If two users modify the same attribute, the last change to be merged takes precedence. PDMS will ensure that all merges comply with the basic database rules, that is, the data will comply with all DICE checking requirements, but it cannot check that the data makes sense in PDMS design terms. It is recommended, therefore, that data consistency and clash checks are carried out on the resulting merged data.

8.7.1 Variants as Owners

A variant can have normal extracts (including working extracts) and other variants created from it. Note that, in this case, the variant forms a new root for claiming elements: claims in extracts below the variant will not be visible from other parts of the extract family, and claims in other parts of the family will not be visible in extracts owned by the variant.

8.8 Extract Sessions

When an extract is created, it is created at a particular session number in the parent extract. This is called the linked session. As the parent extract is modified, that is, as new sessions are added, the linked session on the new extract will not change until a refresh or flush is made. Each extract session will be linked to a specific session in the parent database. This linked session will only change as a result of a refresh. Note: Issuing and dropping cause an automatic refresh. This is best illustrated by the following example.



When a user is making local changes only, the linked session number stays the same. When the user does a refresh, the extract is linked to the most recent version of the parent database. The session number in the parent database will reflect SAVEWORK commands in the parent itself, and also flushes done by users of other child extracts. Example Extract session number

Linked session number in

owner

Comment

1 10 Extract created.

2 10 Modification made on extract.

3 10 Modification made on extract.

4 15 Meanwhile, other changes have been made to the owing database, taking it to session 15. When the extract user does a refresh, the linked session becomes session 15.

5 15 Further modification of extract.

6 18 When the extract changes are issued, the owning database is at session 18, which becomes the linked session due to an implied refresh.

7 18 Further modification.

8 18 Further modification.

9 25 Issued back.

8.8.1 Reverting Extracts

Extracts can be reverted to an earlier session in a similar way to non-extract databases. However, for extracts, the database is not truncated, but a new session is added that is a copy of the required session. This means that unlike backtracking a normal database, reverting an extract can always be reversed. Any elements which are claimed out to users or extracts must exist in the reverted session.



8.8.2 Merging Changes for Extracts

Extracts may be compacted. The following restrictions will apply: • Any sessions linked to child extracts will be preserved. • There must not be any users actively accessing any child extracts. Note: Extracts can be used to maintain the key stages of the design.

8.9 Expunging

Expunging users will release claims by the users. The Expunge Database Claimlists form is displayed when you select Project > Expunge > Claimlist on the main Admin menu bar. It lists all the multiwrite databases in the project. Select the database from which you want to expunge the claimlist and press Expunge.

The Sort By and Filter gadgets are used to control the contents of the list.



8.10 Limits

Maximum number of extracts per DB 8191 Maximum size of extract file 4000 Gbytes Maximum number of elements created per extract 2 000 000 000 Maximum number of ref blocks per extract family 8000 Maximum number of DB numbers 7000 Therefore, maximum number of DBs/extracts 56 000 000 Maximum number of extract levels 10


9 Using Stamps

If you want to determine the changes that have been made to given elements since a specific date, you must compare the relevant session on the DB to the current session. Although you can manage and compare sessions manually, comparing sessions is simpler if you use Stamps to mark the relevant session of DBs, either by specifying a time and date, or a session number. Stamps allow you to ‘mark’ a set of databases at significant stages of a project. You can then use the Stamp name instead of the database name and session number when you are working with databases. Using Stamps with 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 without needing to manually select which sessions to remove. Database sessions included within a Stamp are considered permanent and are not removed when a MERGE CHANGES command is given.

• Backtrack a standard database to a previous session. • Revert an extract database to a previous session. This chapter gives background information about how Stamps are stored in the System database and explains how to create Stamps, how to stamp DB sessions, and how to modify, copy and delete Stamps. For information on how you can use Stamps to merge changes or backtrack changes, see Section 11.8.


Using Stamps

9.1 Stamps and the System Database

When you create a Stamp, a new Stamp element, belonging to the Stamp World element, is added to the System database. The list of DBs to which the Stamp applies is held in the form of Stamp List elements that belong to the Stamp element. Each Stamp List element has two attributes that identify the DB reference and the session number respectively. The diagram below illustrates how this hierarchy is organised within the System database:

For further details about the structure of the System database and the elements in it, see the VANTAGE PDMS ADMIN Command Reference Manual.

STWLD Stamp World

STLST Stamp Lists

STAMP Stamps


Using Stamps

9.2 Creating Stamps

To create a Stamp, set the Element option button on the Admin Elements form to Date Stamps, and press Create. The Create Date Stamp form will be displayed.

Enter a Name for the Stamp, a Description, and a Function. There are several ways that you can select the sessions to be stamped and the databases to be used. Use Set Date to set the time and date to be used to select the sessions to be stamped, or press Now to set the time and date to the current time and date. For the selected databases, the last sessions that are dated


Using Stamps

before the Set Date will be stamped. The default method of selecting sessions to stamp is to use a time and date, although you can select sessions directly instead (see below). Use Stamp to specify how you want to select the databases that are to be stamped. The options are as follows:

Project selects all unique DBs in the project. Any duplicate DBs that have the same DB number are displayed automatically, so that you can choose which of the duplicates you want to stamp. If you decide that you do not want to stamp one of the duplicates, you can choose to skip them completely. Database Sets selects DBs in the selected DB set. MDB selects DBs in the selected MDB. Team selects DBs in the selected team. Databases & Extracts allows you to individually add an existing DB or extract. Working Extract allows you to individually add an existing working extract.

You can select to Stamp database sessions in either of two ways: Date selects sessions by using the Set Date. The last session for the selected databases before the Set Date will be stamped. Session allows you to use the Session gadget below the Databases & Extracts frame to select sessions directly. You can only use this option when stamping by Databases & Extracts or by Working Extract. If the date of a session that you select is not the last session before the Set Date, you will be prompted to confirm your selection.

The databases that match the selected Stamp option are displayed in the selection list immediately below it – the list’s name changes depending on which Stamp option you select. Note the Sort and Filter gadgets at the base of the selection list: see Section 7.4, Sorting and Filtering, for more information. If you select to Stamp database sessions by Session, you can use the Session gadget to display the available sessions for the selected DB. The Stamped Databases frame shows the database sessions that you want to stamp. Select the relevant elements from the selection list and use the down arrow to add them to the Stamped Databases. If you are stamping DBs by Session, you will only be able to select one DB at a time. To remove DBs from the Stamped Databases, use the up arrow or press Remove All to clear the entire list.


Using Stamps

Press Apply, and the new Stamp will be created, with the selected database sessions being stamped. Press Dismiss to close the form.

9.3 Modifying Attributes of Stamps

The attributes of Stamps can be modified using a form that is similar to the Create form. To display the Modify form, set the Element option button on the Admin Elements form to Date Stamps, select the Stamp that you want to modify from the list of Stamps, and then either: press Modify on the Admin Elements form, which will display the Modify form,

or select Modify from the Create/Modify option button on the Create form, if it is displayed, and the mode will change to Modify. You can change the Name, Description and/or Function for a Stamp and add databases to it or remove databases from it. However, if a Stamp has been set by Sessions, you cannot add a database set by Date unless you first remove all the databases set by Session. Note that if you modify the date for a stamp, this does not affect the sessions associated with the stamp. The sessions remain as they were for the original date of the stamp, and are not updated automatically to reflect the stamp’s modified date. You can change the sessions manually.

9.4 Copying Stamps

To copy an existing Stamp, set the Element option button on the Admin Elements form to Date Stamps, select the Stamp that you want to copy from the list of Stamps, and then press the Copy button. The Copy Stamp form will be displayed.


Using Stamps

The name of the Stamp that you are copying appears in the form title. Enter the name for the new Stamp in the To Stamp text box, and, optionally, enter a Description and Function. Press the OK button to copy the Stamp. A copied Stamp references the same databases as the original Stamp.

9.5 Deleting Stamps

To delete a Stamp, set the Element option button on the Admin Elements form to Date Stamps, select the Stamp that you want to delete from the list of Stamps, and then press the Delete button.


10 Data Access Control (DAC)

The basic method of controlling users’ access to data in PDMS is by means of the 'teams owning databases' mechanism – only members of the team owning the database have write access to it. This is always the case, but you can additionally use Access Control Rights (ACRs) to provide a much more sophisticated level of access control. These allow you to: • Restrict users’ access to named elements or given element types, or

to particular volumes of the model. • Restrict the type of operation (for example, Create, Modify or

Delete) that a user can carry out on elements. • Restrict which attributes a user can set or change.

The default PDMS access control will apply to the project unless the Data Access Control option on the Utilities menu in ADMIN is switched on. Note: Once you have switched on Data Access Control, no General users will have write access to any elements unless you have set up ACRs giving them access to those elements. Free users always have full access to all elements.

Data Access Control (DAC) can be applied to Update, Multiwrite and Controlled databases.

10.1 How to Use This Chapter

This chapter explains the basic concepts, and then describes how to fill in the forms to create the ADMIN elements required. Then there are some examples, based on a simple scenario, and finally recommendations on implementation.


Data Access Control (DAC)

10.2 ACRs, Roles and Scopes

Each user can be given one or more Access Control Rights (ACRs). Each ACR consists of two parts: • A Role, which defines what operations a user can carry out on which

elements; for example, create, modify and delete all types of Piping elements.

• A Scope, which defines the part of the design to which the Role applies; for example, a particular Site (in DESIGN) or Registry (in DRAFT), or a specified volume within the model.

Roles and Scopes must be created before you can create ACRs. They are both defined within a project, but Roles are likely to be company-wide and used for all projects, and so they are defined in very general terms, whereas Scopes are project-specific.

10.2.1 Permissible Operations (Perops)

A Role is a set of Permissible Operations (Perops for short) which define the operations that can be performed on a given element type. The hierarchy of ADMIN elements used in DAC is shown below:

Scope

ACR1 ACR2

Role

Perop2 Perop1

User



When a user is allocated a Role (via an ACR), any update operation performed by the user will have to pass a series of tests defined by the Perops owned by that role. Each test (Perop) may either give permission for the operation to go ahead, deny permission for that operation, or the Perop may not be relevant to that operation. In order for a user with this Role to perform one of the operations on an element: • One or more of the Perops in the Role must give the user permission

to perform that operation. AND • None of the Perops must specifically deny the user permission to

perform the operation. A Perop which denies the user permission will override all Perops whose rules give permission.

For each Perop, you define a list of element types that are controlled by that Perop. You then define a list of tasks that the user is allowed to perform on those element types. You may also define a list of tasks that the user is not allowed to perform. If the Perop allows a Modify operation, you can additionally specify a list of attributes of PDMS elements. Permission to change those attributes may be granted or denied by a Perop. Note: A user may have many roles. Only one of these roles needs to

gain permission in order for the user to be given access.



10.3 Creating Roles

Roles are created by setting the Elements drop-down list on the Admin Elements form to Roles and pressing Create. The Create Role form will be displayed.

Give the Role a name and a description. The description is optional, but recommended: when you create ACRs, the description is built automatically from the descriptions of the Role and the Scope.

Now press Apply to create the Role. The Create button will now be active: press it to display the Create Permissible Operation (Perop) form.



Note that the Modify and Delete buttons will only be active when there are Perops to modify or delete.

10.4 Permissible Operations

Enter a Name for the Permissible Operation (Perop) on the Create Permissible Operation form. There are three parts to the definition of a Perop (apart from its name): • The Elements it applies to. • The Operations which can be performed on those elements • The Attributes which can be changed. These parts correspond to areas on the Create Permissible Operation form. After specifying the Elements, Operations, and Attributes (see below for details), press Create to create the Perop.



Options in the Elements Frame The buttons to the right of the scrolling list define whether or not the operations are applied to the elements in the list. The scrolling list is headed: Apply operations to element types if the + button is switched on; Apply operations to all elements except if the – button is switched on. You can add element types to the list by pressing All, or by typing element types, one at a time, into the text box. You can remove an element type by selecting it in the list and pressing Remove. If the Hierarchy box is checked, all the element types owned by the specified types will be included. You can further restrict elements which can be accessed by giving a Qualifying Condition, specified using a PML expression. For example:

ABORE LT 150

You can set an appropriate Message which will be output when a user is refused access to an element because of this Perop.

Options in the Operations Frame The drop-down lists in the Operations frame can be set to: Ignore The Perop does not define user permissions for this

operation. If this setting is used, the user will not be able to carry out the operation as a result of having this Perop, although the user may be able to carry out the operation as a result of another Perop in the Role.

Disallow The user may not perform this operation, even if other Perops in the Role permit it. The error message defined on the form will be output for this operation.

Allow The user is allowed to carry out this operation on the nominated elements, but only if none of the other Perops in this Role specifically disallow the user from carrying out the same operation on that element.

All the lists are, by default, set to Ignore. You must set at least one of the options to Allow or Disallow for the Perop to have any effect. Modify, Create and Delete operations can be performed in all databases. Claim is only used in multiwrite databases; see Chapter 8. Issue and Drop are only used in extract databases; see Chapter 8.



Note: All the operations you require must be specified explicitly. For example, if you select Create, you must also select Modify and Delete if that is what you want. You must also specify Claim if you are going to use multiwrite databases.

Options in the Attributes Frame If the Perop allows the Modify operation, you can use the Attribute List to specify that the operation is only permitted for given attributes of the specified elements. The options in this frame are used in a similar way to the Elements options. The scrolling list is headed: Allow changes to attributes if the + button is switched on; Allow changes to all attributes except if the – button is switched on.

10.5 Examples

The following examples show how you can set up Perops to allow a Role to perform various tasks. Example 1: A Simple Example This Role allows a user to perform all operations on Pipes, Branches and Piping components. Perop Elements Operations Attributes AllPipes Pipe Hierarchy Modify

Create Delete Claim Issue Drop

Allow Allow Allow Allow Allow Allow

ALL



Example 2: Hanger & Support Administration This Role allows a user to create and use Sites for the DESIGN Hangers & Supports application, but not to access Sites for other purposes. The user must first create a Site, and set its PURP attribute to 'ADM'. There are three Perops: the first lets the user do everything with Sites except delete them; the second prevents the user changing the PURP of an existing Site; the third lets the user do everything to Sites which have their PURP attribute set to 'ADM'. Perop Elements Operations Attributes SuppMaster Site Create

Modify Delete Claim Issue Drop

Allow Ignore Disallow Ignore Ignore Ignore

PURP NAME FUNC DESC

Perop Elements Operations Attributes SuppModify Site Create


Ignore Allow Allow Allow Allow Allow

PURP NAME FUNC DESC

Condition: (empty (purp of SITE))

Perop Elements Operations Attributes SuppDelete Site Create



PURP NAME FUNC DESC

Condition: (purp of site eq 'ADM')



Example 3: Creating Support ATTAs This Role allows the user to handle Attachment Points (ATTAs) for Pipe Hangers, but no other type of ATTA. There are three Perops: Perop Elements Operations Attributes ATTA ATTA Create


Allow Ignore Ignore Ignore Allow Allow

ALL

Condition: true

Perop Elements Operations Attributes ATTADENY ATTA Create


Ignore Disallow Disallow Disallow Disallow Disallow

ALL

Condition: (purp of ATTA neq 'HANG')

Perop Elements Operations Attributes ATTADEL ATTA Create



ALL

Condition: (purp of ATTA eq 'HANG')



10.5.1 Messages about Access Denial by DACs

When a user attempts to carry out an operation on an element, and is denied permission to do so, a message will be displayed: • If the user’s Perops allow access to specific elements in the database,

and the user is trying to work with other elements, the message informs the user that access is denied by DACs. No specific reason is given for the denial of access.

• If certain of the user’s Perops allow access to everything in the database, but other of the user’s Perops disallow access to the specific elements in the database that the user is trying to work with, a Perops message informs the user that access is denied by DACs. The message includes a specific reason for the denial of access.

10.6 Creating Scopes

Scopes are created by setting the elements drop-down list on the Admin Elements form to Scopes and pressing Create. The Create Scope form will be displayed.

Give the Scope a Name and Description. The description is optional, but it is recommended: when you create ACRs, the description is built automatically from the descriptions of the Role and the Scope. The Scope Selection is a PML expression. It can limit access to parts of the database defined by an attribute such as PURP, or to a given volume. For example:

ALL WI PURP OF ZONE EQ 'STEEL'

ALL BRAN MEM WI POS gt W10000 S10000 D 10000 and POS lt E10000 N10000 U10000



Note that, unlike Roles, Scopes are project-specific, and they are defined in terms of specific parts of the project data. For example, you can specify a Scope as being a given Site (in DESIGN) or Drawing (in DRAFT).

10.7 ACRs and ACR Groups

ACRs are created by setting the Elements drop-down list on the Admin Elements form to ACRs and pressing Create. You will then see a small form prompting you to say whether you want to create a single ACR or a group of ACRs.

If you press Access Control Rights, the Create ACR form will be displayed. (If you press A group of ACRs, the Create ACR Group form will be displayed; see Section 10.7.2.)

10.7.1 Creating an ACR

On the Create ACR form, give the ACR a Name. Note that the Description is automatically generated from the descriptions of the Role and the Scope, and you cannot change it. Select the Role and Scope required, noting that the names appear in the text boxes below the scrolling lists, and press Apply.



10.7.2 Creating an ACR Group

ACR Groups are created by setting the Elements drop-down list on the Admin Elements form to A group of ACRs and pressing Create. You will then see a small form prompting you to say whether you want to create a single ACR or a group of ACRs. You will normally have created some ACRs before you create an ACR Group.



If you press A group of ACRs, the Create ACR Group form will be displayed.

Give the ACR Group a Name and Description. The description is optional, but recommended. Select the ACRs you want in the group from the Project ACRs list, and use the arrow buttons on the form to transfer them into (or out of) the Member ACRs group. Press Apply. You can now assign an ACR Group to a user. Note that on the Create User form, ACR Groups are indicated by <ACRGRP>, not <ACR>, in the first column of the form.



10.8 How ACRs are Applied

A user can have several ACRs. For example, someone might be able to create, modify and delete all types of Pipework in one area, but only be able to modify certain attributes of Steelwork. When you are planning how to set up ACRs for your users, the main thing to remember is that once DAC is switched on, no General users have write access to anything unless they are given an ACR that allows it. Secondly, the order of ACRs is important. Once PDMS has found an ACR that excludes a user from carrying out a task, it will look no further in the list. For example, if a user has an ACR which only allows modification of Pipes within a given Zone, but not creation, and that ACR is first in the list, the user will not be able to create Pipes in that Zone even if an ACR later in the list allows it.




11 Project Administration

This chapter is an overview of the options on the main ADMIN menu. They are described in the order in which they appear on the menu, reading from left to right. Some of the simpler options are described in full, and some of them have references to other chapters, where they are described in more detail.

11.1 Locking the Project Database

The Project database can be locked using the Lock button on the main ADMIN menu. Locking has no effect on users already accessing a project, but it will prevent other people from entering the project until the project is unlocked. Locking the project may be necessary, for example, to allow a release of newly approved data or to incorporate new versions of the PDMS modules.

11.2 The Options under Admin on the Main Menu

The options under Admin on the main menu are similar to corresponding options in other PDMS modules. Selecting Admin > Save Work will save all changes to the System database. Selecting Admin > Get Work will refresh your view of the System database with changes made by any other (ADMIN) users. Selecting Admin > Session Comment will display the Session Comment form. You can enter text to identify the changes made in your current session. You can see details of previous sessions by using the gadgets on the form to move through the sessions. See the on-line help if you need more information. Selecting Admin > Modules displays a submenu from which you can select the module you want. For modules with graphical user interfaces, you can choose to load from binary files or macro files. See the on-line help if you need more information.


Project Administration

Selecting Admin > Exit will save changes to the System database and exit from PDMS. Note: You cannot QUIT (that is, exit without saving changes) from

ADMIN. This is to ensure that there are no inconsistencies between the actual database files and the record of the databases in the Project stored in the System database.

11.2.1 Abnormal Exits

If you exit abnormally from ADMIN, for example because of a power failure or system crash, and you list the database files in the operating system, you may see files with a .deleted extension. This is because when you do any task that involves deleting a database file in ADMIN, PDMS copies the file to be deleted to a new file with the .deleted extension. When you SAVEWORK, or exit normally which automatically does a SAVEWORK, the .deleted files are removed. However, if there is a problem which results in database files being deleted, and an exit occurs before the System database can be updated with the changes, PDMS will rename the .deleted files and remove the extension, so that the files will still be available.

11.3 Display

Selecting Display > Admin Elements will display the Admin Elements form, if it has been closed. Selecting Display > Command Line will display the Command Input and Output window.

11.4 The Query Options

The options under Query on the main menu allow you to query information about the current user, and list information about any Admin element. See the on-line help if you need further information about these forms.



11.5 The Settings Options

The Settings > Display Mode option allows you to choose whether element names or descriptions are shown on the ADMIN forms. The Settings > Change Password option allows you to set whether or not users can change their passwords. If you select Enabled, users will see a Change Password option on the menu on the main Session Manager window, which will allow them to change their passwords. Otherwise, a password can only be changed within ADMIN.

11.6 The Utilities Options

11.6.1 Integrity Checking

This option displays the Data Integrity Check form. The PDMS Data Integrity Checker (DICE) is described in Chapter 13.

11.6.2 Sending Messages to Other Users

You can send messages to other users by selecting Utilities > Send Message. The Send Message form will be displayed.



You can send a message to one of the following: • An individual user. • 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 change modules or leave PDMS. You can list messages. A message is deleted automatically once it has been displayed.

11.7 The Project Options

The options under Project on the main menu are as follows: Information allows you to add descriptive information about the project. See Section 11.7.1. Font Families allows you to set the fonts used in DESIGN and DRAFT. See Chapter 12. Module Definitions allows you to change the PDMS module definitions. See Chapter 14. Replicate allows you to replicate the project structure. See Section 11.7.2. Expunge allows you to remove phantom users from the project and to release claimed elements after an abnormal exit. See Section 11.7.3. Data Access Control allows you to switch DAC on and off. You will be prompted to confirm that this is what you want to do: for information about DAC, see Chapter 10.

11.7.1 Project Information

You can add descriptive information about the project by selecting Project > Information from the main menu. The PROJECT Information form will be displayed. You can set the Name, Description, Message and Number. The maximum numbers of characters are 119 for Name, Description, and Message, and 16 for Number.



If set, these details are displayed each time the PDMS project is entered. They can be reset in ADMIN at any time.

11.7.2 Replicating a Project

The Project > Replicate options enable you to replicate the whole project, including all the data, or just the structure of the project. The Project Data option copies the current project to a new project. Before you use this option, you must create the project directories and set the environment variables for the copied project. Then enter the new project code on the Replicate Project form. Note: A project must not be replicated outside PDMS by copying the

whole of the Project directory to another Project directory. This is because information about the project name is stored inside the DBs themselves.

The Project Structure option creates a macro which can be run into PDMS to replicate the structure of the current project. No data is copied. When you select this option, a file browser is displayed so that you can give the pathname for the macro. ADMIN scans the System database and outputs to the file all the commands necessary to recreate the project structure, in the following order: • Create users. • Create teams. • Add users to teams. • Create DBs. • Make Copy DBs. • Create MDBs. • Add DBs to MDBs and make them current if appropriate. To create a new project using the generated macro, set up a virgin project using make as described in Section 5.4. Then enter PDMS and run the macro by giving the command:

$m/pathname/ReplicateProj.mac

assuming that you have used the default filename ReplicateProj when you created the macro. To give this command:



• Either start PDMS in tty mode, (that is, without the GUI) by typing pdms tty, and type the command into the window where PDMS is running.

or • Start PDMS with the GUI, select Display > Command Line, and type

the command into the Command window.

11.7.3 Deleting Phantom Users

From time to time a user may exit from PDMS abnormally, for example if there is machine failure or if a system fault occurs. An abnormal exit may leave phantom users in PDMS. The Project > Expunge > All Users option will remove all phantom users from the system. You will be prompted to confirm that this is what you want to do. The Project > Expunge > User Process option will display the Expunge form. The current process is shown by an asterisk. ADMIN will not let the current user be expunged. The Project > Expunge > Claimlist option displays the Expunge Database Claimlists form. This option is used if an abnormal exit has left elements claimed out to a user. From the list on the form, select the database from which you want to expunge the claimlist and press Expunge.

11.8 The Data Options on the Main Menu

The Data options on the main menu are as follows: The Data > Change Management options allow you merge and backtrack PDMS sessions. See Section 11.8.2. The Data > Inter DB Macros option allows you to manage the macros generated by PDMS when a user needs to write to a database to which they do not have access. See Section 11.8.3.



The Data > Extract Database Control option displays the Extract Database Control form, which allows you to see the extract hierarchy in your project, and to refresh, release, issue and drop changes to extract databases. See Chapter 8 for information about extracts.

11.8.1 Merging Sessions

PDMS sessions enable a history of changes to the database to be recorded. When a new session is made, the changed data is appended to the end of the database file. Appending updated data to files will increase the disk space required. If the history information is not required, and to save disk space, you can compact a database by merging sessions. You can specify that the changes up to or after a given date, session number or Stamp will be merged. For example, there may be a session which corresponds to a project milestone which you need to keep, in which case you can merge the sessions around this. In other cases you may wish to merge all sessions up to a given date, within a given week or after a specific Stamp. Merging the database sessions has no effect on any database references into that database from other databases.



To merge sessions, select Data > Change Management > Merge Changes from the main ADMIN menu. The Merge Changes form will be displayed.

You can merge the changes to All Project Databases, the System databases, or the Single database selected above. If you choose All Project databases, you can merge all changes, or changes up to or after a given time, date, session number or Stamp. If you choose System database, you can merge changes up to or after a given time, date, session number or Stamp. If you choose Single database, choose a database from the Available databases list. The Database Sessions button will display the Database



Sessions form, which lists information about the existing sessions for the database. The Rebuild list button is used to update the list of databases. For example, if a new database has been created while the form is displayed, the list will not be updated until the form is closed and re-displayed, or the Rebuild list button is pressed. (See Section 8.8.2 for information about merging sessions in extracts.) After specifying the sessions to merge, press the Apply button to merge changes. Some session data will be deleted. The sessions remaining are those that you have either kept deliberately, or stamped sessions, as these are considered permanent and are not merged.

11.8.2 Backtracking Sessions

You can return a database to the state it was in at a previous session. You can backtrack using the Data > Change Management > Backtrack Changes option on the main ADMIN menu. The Backtrack Changes form will be displayed.



Select the database required from the list. You can backtrack changes by specifying a time, date, session number or Stamp. Note: Subsequent sessions will be lost, so you may wish to copy a

database before backtracking. You can backtrack to the date, session number or Stamp required.

The Rebuild list button is used to update the list of databases. For example, if a new database has been created while the form is displayed, the list will not be updated until the form is closed and re-displayed, or the Rebuild list button is pressed. (See Section 8.8.1 for information about reverting extracts to an earlier session.)



11.8.3 Inter-DB Macros

Inter-DB macros are created in the following situations: • A user in DESIGN attempts to make a connection to an element

which is in a Design database to which the user does not have write access,

• A user in DESIGN attempts to make a connection to an element which is in a multiwrite Design database to which the user has write access, but the element is already claimed by another user.

• A user in ISODRAFT updates REVISION and DETAIL attributes, which need to be stored in the Design database, to which the user has no access.

In these cases an inter-database connection macro will be created. For example, if the current project is sam, the inter-database connection macro will be created in directory sammac with filename samnnn.mac. When the user who does have write access to the second database enters PDMS, a message that there is an inter-database connection macro to be run will be displayed at the bottom of the PDMS MONITOR form. Any inter-DB macros can be displayed by selecting Data > Inter-DB Macros from the main ADMIN menu. The Inter-db Macro form will be displayed. A macro can be deleted by selecting it in the scrolling list and pressing Delete. This allows the administrator to delete any macros, not just the macros for the current team.



11.9 Distributed Databases

It is sometimes necessary to split a project between different geographical locations, directories, disks or even machines. All links between the portions of the project are maintained. There are three ways in which a project may be split. These are: • During its creation • By copying • By moving the relevant databases. Example Assume there is a network of computers, including two known as PC1 and PC2. PC1 is the server and as such holds the PDMS software. In addition to this it also holds the System database for a project called ABC000. Directory ABC000 contains the project’s database files, for example, ABC001 to ABC011. Let us assume we wish to move database ABC002 to computer PC2’s disk. Before we can move the database we must create a directory for it on the target machine, PC2. The name given to this directory is not important, but should follow some sort of naming convention. What is important is the name given to the environment variables which show the location of the database. To work out the required variable name, take the three letters of the project name and append the area code that you wish to allocate to the target directory. There is no significance in the numbering used for these areas, although sequential numbering helps you to remember areas already used. Note: The area number must be in the range 1-999. For example:

Project Name = ABC000 Area Code = 500 Environment Variable name = ABC500

For example: To specify that the area ABC500 is on drive d:

set ABC500=d:\pdmsproj\newarea Note: Environment variable names (ABC500 in the above example) must be in

uppercase characters.



When selecting an area number, it is suggested that a number much higher than the number of available databases is used. Areas can be listed using the LIST AREA areano command, which gives a list of the databases in the specified area. Once you have created the area and set the environment variable for it, you can create or move a database to the area by setting the Area Number on the Create/Modify Database form (to 500, in this example). Pressing the System button next to the gadget will reset the area number to the system default (0).

11.9.1 Global Databases

You can split a project so that its data is distributed across a number of locations by making the project into a Global project. The PDMS users in the different locations access the same PDMS project. The project’s distributed nature is largely invisible to the users. Each location has its own local copy of the PDMS product, and local copies of PDMS databases. To ensure the integrity of data, the project databases are automatically checked and incremental updates are issued across all project sites. Before you set up a Global project, you must understand the basic concepts involved, and you must carry out some preparatory steps. For detailed information about the PDMS Global management concepts, and about how to set up and manage a Global project, you are advised to read the VANTAGE Plant Design Global Management User Guide. You are also advised to take a full backup of your project, as the process of making a standard project into a Global project cannot be reversed using PDMS. Then, to make a Global project, you simply issue a MAKE GLOBAL command from the ADMIN command window. This command splits the System database, creating a local System database and a Global database. The project becomes a Global project based at one Location, known as the Hub. Such a single-location Global project behaves like a standard project as far as most PDMS users are concerned. However, the project can now be split over multiple locations.




12 Font Families

The System database stores details of four font families, numbered 1-4. These families may be defined using ADMIN itself, or the commands can be included in the makemac.mac macro used to create the project. All four families are used by DRAFT, but only the first is used by the other graphical modules. Note that all PDMS font files have the suffix .gfb.

12.1 Introduction to Font Families

A font family combines a character set with a character style.

12.1.1 Character Sets

A character set is specified by name or by a CADC code number derived from its International Registration (ISO-IR) number or from its ISO 8859 part number. The available character sets are: Name Code Description Latin-1 885901 ISO 8859-1 Latin alphabet No. 1 Latin-2 885902 ISO 8859-2 Latin alphabet No. 2 Latin-Cyrillic 885905 ISO 8859-5 Latin/Cyrillic alphabet UK 4 Standard UK ASCII (ISO 646 Reg 4) US 6 Standard US ASCII (ISO 646 Reg 6) Greek 18 ISO 2375 Registration 18 Cyrillic 37 ISO 2375 Registration 37 The ISO 8859 sets contain all the characters of the standard US ASCII set plus ranges of extra punctuation marks, symbols, accents, accented characters, and combined characters.


Font Families

Latin-1 provides additional characters for the following languages: Danish Dutch Faroese Finnish French Icelandic Irish Spanish German Norwegian Portuguese Swedish Italian

Latin-2 provides additional characters for the following languages: Albanian Czech German Hungarian Polish Rumanian Serbo-Croatian Slovak Slovene

Latin-Cyrillic provides additional characters for the following languages: Bulgarian Byelorussian Macedonian Serbo-Croatian Ukrainian Russian

12.1.2 Character Styles

The character styles are also specified by name or code number. The available styles are:

Name Code Line 1 Block 2 Serif 3 Italic 4 Script 5 Typewriter 6 UWLine (Uniform Width Line)

7

Styles 1 to 5 are proportionally spaced; that is, the spacing of the characters varies depending on the characters. Styles 6 and 7 have fixed spacing and so are better for the construction of lists or tables, where items must line up vertically. Not all styles are available for every character set. An error will be output if a specified combination is not available.


Font Families

12.1.3 User-Defined Fonts

A font family may also be defined by two user-supplied font files. One file is used to define the standard character set and the second (optional) file to define a bold version of it. These user-supplied files must be in PDMS font-file format and have the suffix .gfb. AutoCAD character shape files (.shp format) can be converted to .gfb format using the Font Converter supplied as part of the PDMS Software Developer's Kit. For details contact your local AVEVA Solutions Support office, as shown on the copyright page of this manual.

12.1.4 Sloping Fonts

For each font family, you can define an angle of slope between +85 and –85 degrees inclusive. This will cause the text to be sloped forwards (positive angles) or backwards (negative angles).

12.2 Setting Up Font Families

Select Project > Font Families from the main menu, and the Font Family Definitions form will be displayed.


Font Families

The Font Directory sets the directory where the font files are stored. The Current Font Settings show the four fonts that are available. It shows whether they are system-defined or user-defined, the character set (type) and style. You can change the definition of the font selected in the list by changing the settings on the rest of the form. Note: From PDMS Version 11.4, the default character set for the

Project may be Latin-1, Latin-2 or Latin-Cyrillic. All fonts in the font families must be of the same type as those specified for the Project. You cannot mix character sets within a Project.


13 Data Integrity Checking

This chapter describes the PDMS Data Integrity Checker, known as DICE. You may find it useful to read Chapter 4, The PDMS Database Management System, before you read this chapter. DICE checks the internal structure of a database. The main checks are: • Is the complete data hierarchy intact? For example, do all lists

contain all of the members that they should contain? • Are all element names correctly stored and accessible? • Are references to other databases valid? If not, a warning will be

output. The most likely cause is a deleted database. If the answer to any of these questions is no, a message will be output, either to your screen or to a named ASCII file in your working directory. DICE also tells you how many elements are stored. The most probable causes of database corruption are: • An error in the network, resulting in loss or non-arrival of data. • An error on copying databases. In particular, this can lead to

truncated databases. • Insufficient disk space or storage quota, so that the project area fills

up while a database is being updated. • Deletion of a DB which is referenced from another DB. • Reconfiguration of a DB without a corresponding update of all DBs

which have references pointing into it. • An undetected fault in the PDMS Database Management software

(see Chapter 4, The PDMS Database Management System). It is important that any corruption which does occur is detected as quickly as possible, so that the System Administrator can replace the faulty database by a backup copy. For this reason, DICE is designed to operate as fast as possible, using relatively little computer resource, so that it is economic and practical to check the whole of the project database on a regular basis, and not just when an immediate need arises, such as after a computer failure. It is recommended that DICE checks should be run frequently; for example, before a daily backup is taken. DICE should be run at least once a week.


Data Integrity Checking

13.1 Database Storage Statistics

During the checking process, DICE can output statistics about the contents of the database, with very little extra resource usage. The following statistics can be produced: • The total number of elements in the DB • The number of referenced names in the DB

13.2 Preparatory Steps before Checking Starts

A summary of most of the project information stored in the System DB can be obtained by using the Query options. This may be helpful when deciding which DBs need a detailed check. Although DICE can never alter the contents of a DB which it is checking, it always accesses the DB in Read/Write mode, to prevent anyone using the database while it is being checked. You cannot, therefore, check any DB which is in use elsewhere. You can use the Query options to see which other users are currently accessing the project, which DBs they are using, and what their access mode is to each. You may wish to lock the project by pressing the Lock button on the main menu. Locking prevents any more users from entering the project, although current users will be able to continue working.



13.3 Using DICE

Select Utilities > Integrity Checker from the main menu, and the Database Integrity Check form will be displayed.

The Check options at the top of the form allow you to choose which databases you want to check. If the option button is set to Selection, you can pick the databases you want from the list. Select All selects all the databases in the list, and Clear Selection clears the selection.



The other options under Selection allow you to check: • the System database; • the MISC database; • the COMMS database; • all databases in the project - this could take some time. The Settings options control the types of check carried out, and they are described in the following sections.

13.3.1 Producing Statistics

STATISTICS OFF specifies that no statistics will be generated. STATISTICS ON causes DICE to produce a statistical summary of the DB, including its size, the number of elements contained within it, etc.

13.3.2 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 the NOCHECK option is set, DICE does not cross-check any references to other DBs. If CHECK is set, each referenced element is checked to see if it is a valid type. A non-fatal error message is produced for each invalid external reference found. The following tests are applied to each external DB to which reference is made: • Does the referenced DB still exist? • Is the referenced DB a valid type? For example, a reference

attribute in a DESIGN DB which points to a DRAFT DB must be illegal.

• Is the position pointed to within the limits of the referenced DB? Note that for a copied DB, DICE only checks that the reference is within the limits of the largest copy.

A non-fatal error message is produced for each invalid external reference found. The REJECT option should normally only be used when you are certain that the database which is being checked should not contain any external references, for example, to a Dictionary database. If this command is



used, any external reference found in the database will be reported as a fatal error and further checking will be abandoned. If databases have been copied, the references will be checked against the first copy found. If you specify the EXTERNAL CHECK option, you can specify a Preferred 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. . 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.

13.3.3 Using the Patch Option

By default, DICE checks the integrity of the selected database(s), but does not attempt to correct any inconsistencies that it may find. However, if Attempt to patch database problems is check marked (which sets this option to ON) then certain inconsistencies are corrected automatically. For example: • When a child extract recorded in the system database is not listed in

the database header, the extract is added to the database header. • When a child extract is listed in the database header but not recorded

in the system database, the extract is removed from the database header.

• When a claimed element is not recorded as claimed in the parent extract’s claim list, the element is claimed from the parent extract.

• When an element that is not claimed is recorded as claimed in the parent extract’s claim list, the element is released in the parent extract.

• When an element is recorded as being claimed to an extract that is not a child extract, the element is released.

In these cases, the error message is written as a warning. If the patch is successful, this will then be followed by a message indicating the corrective action that has been taken. If the attempt to patch fails for any



reason (for example, if it is not possible to obtain write access to the database) then an error message indicating this will be written instead.

13.3.4 Checking Extract Claimlist Integrity

If Check extract claimlist integrity is on, DICE 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 Attempt to patch database problems 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.

13.3.5 Maximum Errors

There are two type of error detected by DICE: • A fatal error is identified if the DB is corrupted. • A non-fatal error (a warning) is identified if DICE encounters a

fault with references to external DBs. If you set Maximum errors to 1, checking stops when the first fatal error is encountered; that is, DICE simply determines whether or not the DB is corrupt. Otherwise DICE continues checking the whole DB or file, listing all non-fatal and fatal errors until the Maximum fatal errors count or Maximum warnings count is exceeded, when the 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 the DB has been truncated.

13.3.6 Selecting the Output Destination

You can send the reports generated by DICE to your screen or to a named file.



When the form is complete, press Apply, and the selected databases will be checked.

13.4 Macros

Normally the System Administrator will set up standard macros for the regular use of DICE. DICE has two modes of operation: • From within PDMS. This is the normal way of using DICE. You can

use it to check a single DB, several DBs or a whole PDMS project. You can use the Database Integrity Check form for a quick interactive check, or you can write a macro.

• As a stand-alone program. This is useful, for example, when the System DB has been corrupted. DICE can be used to check the System DB from outside the PDMS project. In stand-alone mode, DICE can only check database files one at a time.

The commands needed to write DICE macros, or to run DICE as a stand-alone program, are described in the VANTAGE PDMS ADMIN Command Reference Manual. Some of the commands in DICE can only be used from within PDMS, some can only be used in stand-alone mode and the rest are available in either mode. DICE detects which mode it is operating in and rejects any inappropriate commands.

13.5 DICE Output

As each DB or file is checked, a report is sent to the screen or a file. The basic report, produced in response to any CHECK command, consists of three sections: A report header, which includes information about the date and time of the check, the general details of the DB which is to be checked (DB name, DB number, filename, size, etc), and the options selected. An error report, which lists details of any errors encountered during the checking process. This will contain just one error and any number of warnings in BRIEF mode, but up to the number of errors and warnings specified by if FULL has been specified. A report summary, which tells you whether the DB is free from structural faults, suspect or definitely corrupt.



Other output sections, which will be appended to the basic report if they have been requested, are:

DB storage statistics An external reference list

13.5.1 The Report Header

All the information which DICE can determine about a DB before starting its detailed checks is presented in the report header. The format of the header is as follows: Vantage PDMS Admin Mk11.6.0 (WINDOWS-NT 5.0) (9 Sep 2004 : 02:37)

(c) Copyright 1974 to 2004 AVEVA Solutions Limited

DEVELOPMENT test version - NOT for production use

Issued to AVEVA Solutions Ltd - Complete License

*****************************

* DATABASE INTEGRITY REPORT *

*****************************

Date 10 Sep 2004 Time 11:20

Project ABC

Database ADMIN/PADD Filename /%ABC000%/abc013

DB number 7203

Extract number 1

DB type PADD

DB size 299 Pages

(0.612 Million bytes)

Maximum size 2000 Million Pages

DB is 0% full

Page size 2048 bytes

Last session Number: 3

Last Session Date: 14:40 17 Jan 2003

Last Session User: lbr

Last Session Description: Db modified Options requested STATISTICS OFF CHECK CLAIM LIST FULL CHECK



DICE Banner. This is repeated at the beginning of each report, in addition to its display when first entering the module. It confirms the particular version of DICE which produced the report. Date and Time. The date and time at which the check was started for that particular DB or file. Project. The three-character PDMS project code. Database. The name by which the DB is known within the PDMS project. Filename. The name of the external file containing the DB. DB number. The DB identification number, as it appears in the output from the LIST FILES command. DB type. Design, Catalogue, Drawing etc. DB size. The amount of space, in pages and megabytes, currently used by the DB in its file. Also shown are the maximum size (in pages) and the percentage of space filled. Note that if the database is more than 90% full, the space filled is output as a warning. Page size. The number of bytes per file page. Options requested. Confirms the settings of the checking options:

STATISTICS OFF or BRIEF STATISTICS or STATISTICS ON CHECK EXTERNAL REFERENCES LIST REFERENCED DATABASES BRIEF CHECK or FULL CHECK

Finally the report summary and the error report will be given, as described in the following sections.

13.5.2 The Error Report

During the checking of the structure of each DB, DICE will output a diagnosis of each error as it is found. These messages, which are output as part of the normal operation, are quite distinct from any general error messages which may result from the incorrect running of DICE as a PDMS module. If a BRIEF mode is required, DICE will diagnose any number of warnings up to the first error found and will then abandon any further checking. BRIEF mode is selected by setting the Maximum number of errors on the Database Integrity Check form to 1. If a FULL mode is required, DICE will output a list of all errors found, unless the number of errors exceeds the setting of Maximum number of



errors or the number of warnings exceeds the setting of Maximum number of warnings.

13.5.3 The Report Summary

This overall assessment of the DB integrity is often the most useful part of the report to the user. The following messages can be output:

*DATABASE CONTAINS FATAL ERRORS**

The DB must NOT be used further in the context of a PDMS project and a backup copy must be retrieved to replace it.

Any occurrence of DB corruption should always be reported immediately to AVEVA Solutions Ltd and documented in the usual way on a fault report.

Sometimes a corrupted database can be recovered by reconfiguration, but this is not guaranteed.

Database has no structural errors

The DB can continue to be used. WARNING! Database contains some reference attribute warnings

For example, a reference pointing to an element which has been deleted has been found. The database can continue to be used, but the inconsistencies may need further investigation.


14 Modules

The modules are set up in the supplied product, and you will not normally need to create or edit module definitions in order to run PDMS. The only part of the definition that you may wish to change is the initialisation macro (imacro), which is run on entry to the module. The initialisation macro typically contains module-specific commands to set up the screen display, including loading application macros.

14.1 How Modules are Defined

Each module has an entry in the System database, which consists of the MODULE command followed by commands to specify: • The security for the module:

General modules can be accessed by General users; Restricted modules can only be accessed by Free users; Free modules can be accessed by any user.

• The runfile. • The initialisation macro (imacro), which is run on entry to the

module. • The Read/Write access to database types. For example, DESIGN

needs Write access to DESIGN database, but Read access to Catalogue databases.

• The buffer size.

14.2 The Module Definition Form

The Module Definition form is displayed when you select Project > Module Definitions from the main ADMIN menu bar. This form allows you to create and edit modules definitions for the current project. The Modules window lists the PDMS modules. The Sort by gadget controls the order in which modules are displayed in the list.


Modules

The Copy button displays the Copy Module form. This form allows you to create new modules by copying existing module definitions. This form allows you to specify the Number and Name of the new module. Delete deletes a module definition from the project. You will no longer be able to use the module in the current project, unless you redefine it. The Settings window displays the settings for the module selected in the Modules list. You can change all of these except the Number and Name. Security can be set to Restricted, General or Free. Runfile sets the file used to start up the module. The defaults are supplied in the %PDMSEXE% directory. Imacro sets the file used to start up the GUI for the module. The default is given by the %ADMSTART% variable. The Advanced button displays the Advanced Module Settings form. This form allows you to set the buffer size (see next section), the default database type and access for the module. Note: Changing the options on this form may cause serious problems

when using PDMS. The form is for expert use only.

14.3 Setting the DABACON Buffer Size

Each module definition in the System DB may include a BUFFER command. This command specifies how much space is to be reserved for the DABACON buffer in each module, and allows the database constructor to trade off CPU usage against disk I/O to some extent and thereby optimise computer efficiency in some of the more heavily used modules. If the module definition does not include a buffer size, the default buffer size of 5,120,000 words (20MB) is used. The maximum is size is 51,200,000 words (200MB). The modmac macro sets the buffer size for all modules (except the Global daemon) to 12,800,000 words (50MB); you are advised to leave it at this. If the environment variable PDMSBUF is defined by a user, this overrides the value from the BUFFER command – this can be used to change the amount of memory used on machines with particularly large or small amounts of free memory. Users are advised to contact AVEVA Solutions Ltd if they have any doubts about the setting of their buffer sizes. The syntax used to set up the size of a buffer in ADMIN is either:


Modules

BUFFER integer (where integer is the required buffer size in words)

when the module definition is being created (e.g. in the project module definition macro) or:

EDIT MODULE moduleid BUFFER integer

where an existing module definition is being edited. integer is the number of words to be reserved for the buffer. The buffer can be reset to its default value at any time. For example:

ED MOD ISODRAFT BUF DEF

would reset the ISODRAFT buffer size to its default value.


Modules


Appendix A. Menu Maps

VANTAGE PDMS ADMIN User Guide A-1 Version 11.6

aveva

Insert Menu Maps


A-2 VANTAGE PDMS ADMIN User Guide Version 11.6

Modules

PDMS ADMIN User Guide A-3 Version 11.6


A-4 VANTAGE PDMS ADMIN User Guide Version 11.6

Index

.deleted files, 11-2

Abnormal exit, 11-6

Abnormal exits, 11-2

Access Control Rights, 10-1

Access to databases, 3-6

ACR Groups

creating, 10-12

ACRs. See Access Control Rights

creating, 10-11

how they are applied, 10-12

Admin Elements, 11-2

Admin Elements form, 7-3

Administration Databases, 3-1

Area number, 3-5, 7-12

Areas, 11-12

Attribute types, 4-2

Attributes, 4-1

of teams, 7-9

of users, 7-9

Backtracking extracts:, 8-19

Backtracking sessions, 11-9

Buffer size (modules), 14-1

Caliming, 8-13

CATALOGUE databases, 3-1

Change management, 11-7, 11-9

Claim mode, 8-1

Claiming, 8-1

extracts, 8-5

Command Line, 11-2

COMMS database, 3-1, 3-4

CONTROLLED databases, 3-7, 3-9

Copying, 7-9

databases, 7-13

stamps, 9-5

Creating

databases, 7-10

modules, 14-1

stamps, 9-3

Current databases, 7-19

DABACON, 4-1

DABACON buffer, 4-3

DAC. See Data Access Control

Data Access Control, 10-1

Data integrity checking, 13-1

Database

SYSTEM, 3-3

Database files, 2-1

Database ownership, 3-6

database schema, 2-1

Database schemas, 4-1

Database types, 3-1

Databases, 7-16

distributed, 11-12

DB number, 7-12

DB sets, 7-16

DBs, 2-2

VANTAGE PDMS ADMIN User Guide Index-i Version 11.6

Index

DELETE command, 7-10, 7-16

Deleting, 7-10

extracts, 8-13

stamps, 9-6

Deleting databases, 7-16

Descriptions

changing, 7-13

DESIGN databases, 3-1

DICE, 13-1

patch option, 13-5

DICTIONARY databases, 3-1

Display Mode, 11-3

Distributed databases, 11-12

DRAFT databases, 3-1

Dropping

extracts, 8-8

EDMSlink, 3-9

Element types, 4-1, 4-2

Elements, 2-1

Environment variables, 3-3, 5-2

Excluding databases, 7-15

Explicit claims, 8-1

Expunging, 8-20

External references, 13-4

Extract file numbers, 8-12

Extract filenames, 8-12

Extract files, 8-12

Extracts, 8-2

advantages, 8-3

backtracking, 8-19

claiming, 8-5

control, 8-17

copying, 8-12

deleting, 8-13

dropping, 8-8

flushing, 8-7

issuing, 8-8

members, 8-3

merging changes, 8-20

owning database, 8-3

refreshing, 8-7

releasing, 8-8

sessions, 8-18

File number, 3-5, 7-12

Filtering, 7-5

Flushing

extracts, 8-7

Font families, 12-1

Foreign databases, 7-14

GETWORK, 3-8

imacro, 14-1

Implicit claims, 8-1

Included databases, 7-14

Initialisation macro, 14-1

Installing databases, 7-16

Integrity checking, 13-1

Inter-db macros, 11-7, 11-11

ISOD databases, 3-1

Issuing

extracts, 8-8

Leaving ADMIN, 11-2

LEXICON databases, 3-1

Linked sessions (extracts), 8-18

LOCK command, 11-1

Index-ii VANTAGE PDMS ADMIN User Guide Version 11.6

Index

Macros

project setup, 5-3

MAKE.MAC, 5-3

MDBs, 2-2, 3-7, 7-18

Merging changes

Extracts, 8-20

Merging sessions, 11-7

Messages, 11-3

MISC database, 3-1, 3-4

Model databases

relationships, 3-4

Model Databases, 3-1

Modules, 14-1

buffer size, 14-1

changing, 11-1

runfile, 14-1

security, 14-1

Multiple databases, 7-18

Multiwrite databases, 4-1

MULTIWRITE databases, 3-7, 8-1

Mutliple databases, 3-7

Naming conventions, 3-2

PADD databases, 3-1

Passwords, 11-3

Patch option for DICE, 13-5

Permissible Operations, 10-2

Perops. See Permissible Operations

Primary elements, 8-1

Project, 2-1

creating, 5-1

Project code, 5-1

Project Code, 3-5

Project database

locking, 11-1

Project directory, 3-2, 5-1

Project information, 11-5

Project replication, 11-5

Project structure, 3-2

Projects

replicating, 11-5

PROPERTIES databases, 3-1

Pseudo-attributes, 4-3

Querying, 11-2, 11-5

Reconfiguration, 2-3

Reference attributes, 4-2

Reference numbers, 4-3

Refreshing

extracts, 8-7

Releasing

extracts, 8-8

Removing elements, 7-10, 7-16

REPLICATE command, 11-11

Replicating, 11-5

Replicating projects, 11-5

Roles, 10-2

creating, 10-4

Runfile (modules), 14-1

Sample project, 7-16

Savework, 11-1

SAVEWORK, 3-8

schema, 2-1

Scopes, 10-2

creating, 10-10

Session Comment, 11-1

VANTAGE PDMS ADMIN User Guide index-iii Version 11.6

Index

Sessions, 3-10, 4-1

backtracking, 11-9

extract, 8-18

merging, 11-7

Sorting, 7-5

Stamps

copying, 9-5

creating, 9-3

deleting, 9-6

modifying, 9-5

System database, 9-2

Start macro, 14-1

Starting up ADMIN, 7-1

Statistics

storage, 13-2

Storage statistics, 13-2

System Database, 2-1

SYSTEM database, 3-1, 3-3, 3-9

Teams, 2-2, 3-6

Teams,

creating, 7-6

UDAs, 4-3

UPDATE databases, 3-6

Updating databases, 3-8

User-defined attributes, 4-3

Users, 2-2, 3-6

creating, 7-7

deleting, 11-6

Index-iv VANTAGE PDMS ADMIN User Guide Version 11.6

Documents

VANTAGE PLant Design ADMIN User Guide - cadfamily.com User Guide.pdf · local AVEVA SOLUTIONS office. See . VANTAGE PDMS ADMIN User Guide 1-1 Version 11.6 . Introduction to this Manual