LEXICON Command Reference Manual

LEXICON Command
Reference Manual
AVEVA Solutions Limited
Disclaimer
1.1 AVEVA does not warrant that the use of the AVEVA software will be uninterrupted, error-free or free from
viruses.
1.2 AVEVA shall not be liable for: loss of profits; loss of business; depletion of goodwill and/or similar losses; loss of
anticipated savings; loss of goods; loss of contract; loss of use; loss or corruption of data or information; any
special, indirect, consequential or pure economic loss, costs, damages, charges or expenses which may be
suffered by the user, including any loss suffered by the user resulting from the inaccuracy or invalidity of any data
created by the AVEVA software, irrespective of whether such losses are suffered directly or indirectly, or arise in
contract, tort (including negligence) or otherwise.
1.3 AVEVA's total liability in contract, tort (including negligence), or otherwise, arising in connection with the
performance of the AVEVA software shall be limited to 100% of the licence fees paid in the year in which the user's
claim is brought.
1.4 Clauses 1.1 to 1.3 shall apply to the fullest extent permissible at law.
1.5 In the event of any conflict between the above clauses and the analogous clauses in the software licence under
which the AVEVA software was purchased, the clauses in the software licence shall take precedence.
Copyright
Copyright and all other intellectual property rights in this manual and the associated software, and every part of it
(including source code, object code, any data contained in it, the manual and any other documentation supplied
with it) belongs to, or is validly licensed by, AVEVA Solutions Limited or its subsidiaries.
All rights are reserved to AVEVA Solutions Limited and its subsidiaries. The information contained in this document
is commercially sensitive, and shall not be copied, reproduced, stored in a retrieval system, or transmitted without
the prior written permission of AVEVA Solutions Limited. Where such permission is granted, it expressly requires
that this copyright notice, and the above disclaimer, is prominently displayed at the beginning of every copy that is
made.
The manual and associated documentation may not be adapted, reproduced, or copied, in any material or
electronic form, without the prior written permission of AVEVA Solutions Limited. The user may not reverse
engineer, decompile, copy, or adapt the software. Neither the whole, nor part of the software described in this
publication may be incorporated into any third-party software, product, machine, or system without the prior written
permission of AVEVA Solutions Limited, save as permitted by law. Any such unauthorised action is strictly
prohibited, and may give rise to civil liabilities and criminal prosecution.
The AVEVA software described in this guide is to be installed and operated strictly in accordance with the terms
and conditions of the respective software licences, and in accordance with the relevant User Documentation.
Unauthorised or unlicensed use of the software is strictly prohibited.
Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved. AVEVA shall
not be liable for any breach or infringement of a third party's intellectual property rights where such breach results
from a user's modification of the AVEVA software or associated documentation.
AVEVA Solutions Limited, High Cross, Madingley Road, Cambridge, CB3 0HB, United Kingdom.
Trademark
AVEVA and Tribon are registered trademarks of AVEVA Solutions Limited or its subsidiaries. Unauthorised use of
the AVEVA or Tribon trademarks is strictly forbidden.
AVEVA product/software names are trademarks or registered trademarks of AVEVA Solutions Limited or its
subsidiaries, registered in the UK, Europe and other countries (worldwide).
The copyright, trademark rights, or other intellectual property rights in any other product or software, its name or
logo belongs to its respective owner.
LEXICON Command Reference Manual
Revision Sheet
Date Version Comments / Remarks

September 2011 12.1.1 New Calculation of UKEY section added.
January 2012 Copyright added to all pages.
Contents Page
Reference Manual
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
LEXICON Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
User Defined Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1

UDA Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:2
Valid Values and Valid Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:5
Valid Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:5
Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:6
Create New UDAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:7
Copy UDA Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:7
Example UDAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:8
UDAs in User Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:12
Set and Change UDAs in User Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:13
Query UDAs in User Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:13
Use of GOTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:14
Effect on UDA Instances if Definition is Changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:14
Purging UDA Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:14
Expressions and Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:15
UDAs in Data Output Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:15
UDAs in Project Reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:15
Reference External Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:15
User Defined Element Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
Copyright 1974 to current year. i 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
UDET Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2

Create a UDET Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2
Redefine the Owner and Member List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:3
Hide System Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:4
Delete a UDET Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:4
UDATLS Pseudo Attribute on a UDET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:4
Presentation within the Constructor Modules and ADMIN . . . . . . . . . . . . . . . . 3:4
Use of TYPE at the PML Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:4
Collections and Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:5
Change Type on an Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:5
Element UDET Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:6
Purge Report on MDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:6
SPEC Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:6
GTYP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:7
User System Defined Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1

USDA Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1
USDA Limits and Valid Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:2
Create a USDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:2
Database Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:1

Definition Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:1
Database View Elements and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:2
DBVWSE Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:4
DBVW Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:4
ATTFIL Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:4
EXPFIL Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:5
ATTCOL Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:5
EXPCOL Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:6
SRCELE Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:6
CRERUL Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:7
SETPAR Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:7
SETATT Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:8
SETSTA Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:8
TESTEX Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:9
COLREL Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:9
Copyright 1974 to current year. ii 12 Series

Create a Database View Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:9

Example Database Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:11
UDA Administration View : Real UDAs without Dimension . . . . . . . . . . . . . . . . . . . . . . . . 5:11
Multi-element View : Schematic Equipment/Pipe Connectivity . . . . . . . . . . . . . . . . . . . . . 5:12
Distributed Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1

Distributed Attribute Elements and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1
DSXDST Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:2
DSXTST Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:2
DSXSCH Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:2
DSXOWN Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:2
DSXMBR Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:3
Status Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1

Command Syntax Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A:1
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A:1
Command Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A:2
Syntax Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A:2
Compiling the Element List and Reference List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A:3
<assign> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A:3
Copying a UDA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A:3
<ucopy> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A:3
Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B:1
Copyright 1974 to current year. iii 12 Series

Copyright 1974 to current year. iv 12 Series

Introduction
1 Introduction
The LEXICON module enables the system administrator to configure the project elements
and attributes to meet their needs, to define element status rules and define database views
for import/export, reporting and table based working.
Elements and attributes within a project can be changed by:
Defining new attributes (User Defined Attributes : UDAs)
Adding project constraints to system attributes (User System Defined Attributes:
USDAs)
Sub-typing element types to classify elements (User Defined Element Types: UDETs)
Extending element definitions to enable claims of different attributes at multiple
locations or by different disciplines using distributed attributes.
The Command Reference Manual assumes that the user is familiar with using PDMS at a
System Administrator level. Access to LEXICON is normally restricted to FREE users only.
1.1 LEXICON Database

Before a project can use any of the resources covered in this manual a DICTIONARY
(DICT) database must be created as part of a Multiple Data Base (MDB). Use the ADMIN
module in the same way as for any other type of database. For further information refer to
the Administrator User Guide.
Elements within the LEXICON may be changed or deleted during the course of a project.
The dictionary will contain all the definitions for a project and if data is to be transferred
between PDMS projects the dictionary must be transferred as well. The data output and
project reconfiguration functions can be used to do this. A user may create elements within
other databases such as DESIGN from definitions within the LEXICON database, however if
the LEXICON database is removed then these elements will return to being represented by
their base type in the DESIGN database.
Copyright 1974 to current year. 1:1 12 Series

Introduction

User Defined Attributes
2 User Defined Attributes
User Defined Attributes (UDAs) enable the PDMS system administrator to add new
attributes to any element in the databases of a project. These UDAs are created as
elements in the LEXICON database inside the PDMS project. Because LEXICON
databases are project-specific, it is possible to define attributes to suit individual project
requirements or company standards.
Once defined, UDAs may be accessed in much the same way as normal attributes,
including setting values, querying and reporting upon these values. Utilities such as the
Data Output and Project Reconfiguration functions treat UDAs as they would any other
attribute. UDAs can also be used in expressions.
The hierarchy of elements which make up a UDA within the LEXICON database is shown
below.
UWRL (UDA World) is the top-level administrative element. As well as the standard PDMS
attributes, this has a DESC (description) attribute which can contain up to 120 characters of
text.
A UWRL may hold UGRO (UDA Group) elements or individual UDA (UDA definition)
elements. A UGRO has the same attributes as a UWRL.

2.1 UDA Attributes

UDA elements have the following attributes (besides the standard ones):
UDNAME - the name by which the UDA will be referred to in the PDMS modules that use
UDAs. The name must not be confused with the standard NAME attribute of the UDA, which
is the name of the UDA element within the LEXICON database. The name must be entered
as a text attribute with a maximum length of twenty case-independent characters. An
example of setting the UDNAME attribute would be:
UDNA SUPPORT
ABLEN is the minimum number of characters for a UDNAME abbreviation - default 3. In the
default case, the minimum abbreviation for the example UDNAME given above would be
SUP. When two or more UDAs have the same minimum abbreviation - an error occurs when
the UDAs are compiled, for more information, refer to Create New UDAs.
UKEY. A system attribute, it can be queried but not set directly. It is the number which
identifies the UDA.
It is possible to copy a UDA, with the copy having the same key as the original - for more
information, refer to KEYCOPY command in Copy UDA Definitions.
UTYPE is the UDA type this can be set to the following:
REAL Any numeric value, for example, 23.5
INTeger Any whole number, for example, 200
REFerence An element identifier, for example, /VESS1, =12/99
TEXT Any characters in closing single quotes.

for example, BOT_STEEL2
WORD Any sequence of letters, for example, ABCD
LOGical TRUE or FALSE
POSition A position, for example, E10 N50 U100
DIRection A direction, for example, E 45 U
ORIentation An orientation, for example, U is E and N is D.
DATetime A datetime, for example 17 May 2012 18:00
The UTYPE defines the type of data that may be entered against the UDA for an element
accessed by a user module. POS, DIR and ORI types are particularly useful when used in
conjunction with WRT or FROM. For example:
Q :POS OF /EQUI-1 WRT /*
Note: when WRT is used, the base value is relative to the Owner, not the element itself.
Hence this command will extract the values of :POS for EQUI-1, and concatenate the
values with the values for the Zone and Site. The result will be relative to the World.
ULEN is the maximum number of occurrences of the given UTYPE that may be stored in the
UDA. For example, a REAL UDA might be given a ULEN of 3, making it suitable for storing,
say, a 3D coordinate array. For TEXT and WORD UTYPEs, ULEN is the maximum number
of characters. The default setting of ULEN is 1, the maximum is 120. (Strings longer than

120 characters will be truncated.) ULEN cannot be used on attributes with a UTYPE of
POS, ORI or DIR, a length of 1 is always assumed.
RPTX (Report text) is a text attribute used to define the display name for the attribute. This
is the name that is used as the default column heading in reports. RPTX may be up to 30
characters long.
UUNIT defines the dimension of the attribute so that the values will be unit qualified. The
default is NONE, which means that the UDA value will be output exactly as it is stored and
will not vary according to unit settings. The UUNIT setting is only used if the UDA type is
REAL.
DFLT (Default). A default value for a UDA that hasn't been set or becomes 'unset'. For
UDAs with a UTYPE of INT, REAL or LOG the default will only be used if ULEN is 1. DFLT is
not a valid attribute for UDAs with a UTYPE of REF, POS, ORI or DIR types.
The type of setting entered should correspond to the UTYPE. DFLT may be left unset or set
to NONE. In this case the UDA has no default.
DESCRIPT is a text attribute which may be used to give a description of the UDA.
ELELIST (Element list) contains the list of element types for which the UDA is valid. Up to
100 element types may be set.
The element list must be assembled using the syntax:
ELElist ADD element_type
Elements must be removed from the list by using the syntax
ELElist REMove element_type...
Example:
ELELIST ADD ZONE add ZONE and PIPE elements

PIPE
ELE REMOVE PIPE remove PIPE elements
ELE REM ALL remove all elements
To simplify input the keywords ALLP and PRIM can be used to cover all piping components
and all primitives, respectively.
UDAs can be bound to UDETs.
UDAs may be added to the UDET in the same way that they are allocated to system
element types, for example. a UDET may appear in the ELELIST for a UDA definition.
REFLIST (Reference list), this is only relevant if UTYPE is REF. It is the list of valid element
types that the UDA may reference. For example, if a REF UDA is set in DESIGN to an EQUI
element and the UDA elements REFLIST is set to VALV, then an error will result. If

REFLIST is not set, it is assumed that all element types may be referenced. REFLIST is set
in a similar way to ELELIST, for example:
Example:
REFLIST REM PIPE BRAN
REF REM ALL
REF REM PRIM
The REFLIST may have up to 100 members.

A RELIST may also contain references to UDETs which have been directly derived from a
system type.
UHIDE Setting this to True will indicate that the UDA will be hidden from the Q ATT
command and from the attribute form within PDMS. Querying of the individual UDA will not
be effected by this setting.
UTEAMS If the UHIDE attribute has been set to true then the UTEAMS attribute can be
used to override UHIDE for specific teams. The UDA will then be hidden for all teams other
than the ones specifically declared in UTEAMS. UTEAMS can hold an array of values, for
example:
Example:
UTEAMS /*TEAM1/*TEAM2/*TEAM3
Values may also be input individually for example:
Example:
UTEAMS /*TEAM1
UTEAMS NUM 2/*TEAM2
UTEAMS NUM 3/*TEAM3
UHYPER The attribute holds a logical value, setting this to the true will allow the text value
of a UDA to contain a path to the external file.
UCONN The attribute holds a logical value, setting the value to have will signal that the UDA
is a connection in the reference list.
UPSEUD Setting this logical attribute to True will indicate the UDA is pseudo attribute.
Pseudo attribute allow for dynamic values to be returned as needed rather than having
static values stored in the database.
The code required to return a pseudo attribute value must be plugged in through the use of
the C# API.

UDPEND If the calculation of the pseudo attributes relies on other values on the element,
and the pseudo attribute is to be used in a dynamic rule, then it is possible to denote what
real attributes the pseudo attribute depends on by setting the UDPEND attribute. For
example:
Add a UDA :VOLUME to a box. The provided pseudo code simply multiplies
XLEN*YLEN*ZLEN, so :VOLUME is dependant on XLEN, YLEN, ZLEN. To indicate this set
UDPEND attribute to 'XLEN YELN ZLEN'. If subsequently, :VOLUME is included in a
dynamic rule, and XLEN, YLEN, ZLEN are modified then the result will reflect this. For most
pseudo attributes the setting of UDPEND is unlikely to be needed.
UDTABL defines whether the attribute values are indexed for rapid access. Indexing will
improve performance for searches and collections that use attribute filters. Only use
indexing on attributes that are significant to such collections or searches.
ULVOPT The attribute holds a logical value, setting this optional flag value to True will allow
the value or limit of a UDA or USDA to have a value outside the set valid values or ranges.
2.2 Valid Values and Valid Ranges

The values allowed by a UDA can be limited to a fixed set of values or ranges of values
depending on the UTYP of the UDA. If ULVOPT is set to true on the UDA then these values
become suggestions to the user rather than actual constraints when setting the attribute
value.
2.2.1 Valid Values

The valid values for a text or word UDA can be defined by creating UVALID elements below
a UDA.
The attribute of a UVALID element is:
UVVAL - valid value.
If the administration requires multiple validation criteria then multiple elements must be
created. The following example will create a UDA which will allow values "Warning",
"Danger", or "Caution":
Example:
NEW UDA /STAT UTYP TEXT Create a new Text UDA
UDNA 'STATUS'
ULEN 10
RPTX 'STATUS'
ELE ADD EQUI STRU SUBS PIPE ZONE

SITE
NEW UVALID /WARNING Create a UVALID element to hold a condition
UVVAL ' WARNING'

DESC 'Condition Warning'
/STAT Navigate back to UDA element
NEW UVALID /DANGER Create a second UVALID element
UVVAL 'DANGER'
DESC 'Condition Danger'
/STAT
NEW UVALID /CAUTION Create a third UVALID element
UVVAL 'CAUTION'
DESC 'Condition Caution'
2.2.2 Limits
Valid values or ranges of values for real or integer UDAs can be defined by creating ULIMIT
elements as members of a UDA. Multiple ULIMIT members can be created for a UDA.
The attributes of a ULIMIT element are:
UMIN - Minimum value
UMAX - Maximum value
The following example will create a Weight UDA and limit the input value to between 5kg
and 50kg:
Example:
NEW UDA /WEIG UTYP REAL
UDNA 'WEIGHT'
ABLEN 6
UUNI Mass
RPTX 'Weight'
ELE ADD STRU SUBS EQUI Create UDA Weight
NEW ULIMIT Create a ULIMIT element beneath UDA
UMIN 5kg Set a minimum value of 5kg
UMAX 50kg Set a maximum value of 50kg
DESC Weight Limit

2.3 Create New UDAs

The first step is to create a LEXICON database hierarchy, see User Defined Attributes.
Commands used to create, delete and navigate around the LEXICON database elements
are exactly the same as those used for any other database type: see the Administrator
Command Reference Manual for details.
A typical LEXICON session could be as follows:
Example:
NEW UWRL /UWRL1
NEW UGRO /CENTRE_GRAVITY
DESC Centre of gravity at Create UDA World, UDA Group

tributes
NEW UDA /LENGTH UTYP REAL Create and name UDA, type REAL
UDNA LENGTH Assign user database attribute name,
ABLEN 6 Minimum abbreviation LEN
UUNI DIST Set UDA units as system DISTANCE units
DFLT 0.00 Set default UDA value
Here, the default value of the UDA has been set to zero, but in a case such as temperature
it might be set to be a value of (say) 20.0 to represent an ambient temperature.
RPTX Length Set column heading to be used in reports
ELE ADD STRU SUBS Define element types that are to use the UDA
COMPILE Implement the UDA definition
The COMPILE command reports any definition errors and makes the UDA definition
changes immediately available within LEXICON to other windows such as the Database
Views Editor or the Schematic Model Manager Attribute Mapping dialogue. Without using
the COMPILE command ('Validate' from the LEXICON Edit menu) the UDAs may not be
visible in the windows or dialogues presented. Performing a savework will make the
definitions available to other modules once a GetWork is performed by them.
2.4 Copy UDA Definitions

When a UDA definition is copied, a new key (a reference number known only to the system)
is assigned to the new element. Occasionally you may want to have more than one
definition with the same key; for example, to vary the default or UDA length depending on
the element types. To do this the key may be copied using the command:
KEYCOPY name
rather than the standard

COPY name
Where two or more definitions exist with the same key, the definitions must have the same
name, minimum abbreviation and type, and different ELELISTS, otherwise an error will
occur on compilation. It is advisable to have the same units and RPTX text. Note that project
reconfiguration will always copy the key.
2.5 Example UDAs

The following section gives examples of some of the different UDA types. The commands
for creating each UDA type are given, together with a brief discussion of their features.
Note: When a UDA appears in the attribute list of a user element, its name (that is, its
UDNAME) will be preceded by a colon (:) to distinguish it as a UDA.
The following example is of a REAL attribute which can be used to store the weight of an
element.
Example:
UDA type REAL
NEW UDA /WEIG UTYP REAL
UDNA WEIGHT
ABLEN 6
ULEN 1
UUNI Mass
RPTX Weight
ELE ADD STRU SUBS EQUI
The following example of a TEXT attribute which can be used to store the name of the
person who has checked a particular element. After checking, the checker would set the
attribute to his name.
Note: The disparity between the length of the text string (ULEN) and the report text
(RPTX). In this case, the text length is six characters for the attribute, but the report
text is set as being 10 characters long. The Reporting utility will set its column width
to whichever is the largest; there is little point in having only six characters for the
attribute when 10 characters will be allowed anyway. Conversely, if six characters
are all that is required, then the RPTX should be cut down to reduce the column
width.

Example:
UDA type TEXT
NEW UDA /CHKD UTYP TEXT
UDNA CHKD
ULEN 6
RPTX Checked By
ELE ADD EQUI STRU SUBS PIPE ZONE SITE
The following example is of a DATE attribute that can be used to store the change date.
Example:
UDA type DATETIME
NEW UDA / MODDA UTYP DATE
UDNA NODDATE
ABLEN 6
ULEN 1
RFTX Modified
ELE ADD EQUI PIPE STRU
The following example of a LOGICAL attribute is used to store either TRUE or FALSE to
indicate one of two conditions. In this case, the attribute is intended to indicate whether an
item has been pressure tested or not. ABLEN allows the attribute to be accessed as either
:TEST, :TESTE or :TESTED.
Example:
UDA type LOGICAL
NEW UDA /TEST UTYP LOGICAL
UDNA TESTED
ABLEN 4
DFLT FALSE

Example:
RPTX TESTED
ELE ADD BRAN EQUI
The following example of a REFERENCE attribute allows a number of piping components to

be referenced to Structural items or Equipment. As the name suggests, this attribute could
be used to indicate the name of a Structural element which is supporting a Component. The
attribute would be set in the database in the same way as other reference attributes, for
example. :SUPP /COL-A1.
Note that the REFLIST attribute has been set such that the UDA in the user element (that is,
the :SUP attribute) can only be set to an identifier relating to a Structure, a Substructure or
an Equipment.
Example:
UDA type REFERENCE
NEW UDA /SUPPORT UTYP REFERENCE
UDNA SUPPORT
ULEN 50
RPTX Support reference
ELE ADD ELBO TEE REDU FLAN VALV CROS CAP ATTA PCOM
ELE ADD OLET INST
REF ADD STRU SUBS EQUI
The following example shows how a WORD attribute can be set up to show the normal state
of Valves; for example, whether they are normally open or normally closed. The value
assigned to this attribute in the DESIGN would probably be either OPEN or CLOS. For this
particular example, a default value is inappropriate, so the DFLT attribute is left unset and
no default is shown in the DESIGN. As with other unset attributes, the default text --- will be
output in reports whenever an attribute with no default value is encountered.
Example:
UDA type WORD
NEW UDA /OPERATION UTYP WORD
UDNA OPERATION

Example:
RPTX Normal Operation
ELE ADD VALV
The following example of a POSITION attribute which can be used to store the position of
the centre of gravity of an element. Because arrays of Position attributes are not supported
ULEN is set to 1. Moving the element using AT or BY commands will not change the values
stored in COFG, unless they are linked by a Rule. For example:
:COFG DYNAM (N 100 WRT CE)
Then, if the element is moved :COFG is reset automatically.
Example:
UDA type POSITION
NEW UDA /COFG UTYP POS
UDNA COFG
ULEN 1
UUNIT DIST
RPTX Centre of gravity
The following example of an ORIENTATION attribute which can be used to store the
orientation of an element. Because arrays of Orientation attributes are not supported ULEN
is set to 1.
Example:
UDA type ORIENTATION
NEW UDA /HAND UTYP ORI
UDNA HANDWHEEL
ULEN 1
RPTX Handwheel
ELE ADD VALV
The following example of a DIRECTION attribute. Because arrays of Direction attributes are
not supported the ULEN of this attribute is set to 1.

Example:
UDA type DIRECTION
NEW UDA /ACCESS UTYP DIR
UDNA ACCS
ULEN 1
RPTX Access
2.6 UDAs in User Elements

UDAs are applicable to all database types.
Having defined and compiled a set of UDAs in LEXICON, those elements defined as using
UDAs will have the UDA UDNAME, preceded by a colon and followed by the UDAs default
setting, added to their standard attribute lists. For example, suppose an INTEGER UDA has
been defined as follows:
Name /INT
Lock false
Owner /UGRO1
Udname CAPACITY
Ablen 3
Utype INT
Ulen 1
Rptx text
Dflt 80
Descript text
Elelist SITE
Reflist
Querying the attributes of a SITE element in DESIGN would give something like:
Name /SITE1
Lock false

Owner /*
Position E 0mm N 0mm U 0mm
Orient
Y is N
and Z is U
:CAP 80
The UDA instance, that is, the reference to the UDA definition, appears at the end of the
attribute list, with a colon as its first character.
2.6.1 Set and Change UDAs in User Elements

A UDA instance is set using the syntax
:Udname setting
where setting could be an integer, a value, text, and so on, depending on the UDA type. An
example of (re)setting the CAP attribute above could be:
:CAP 101 - reset CAP value to 101
Array attributes may be set or changed as shown by the following examples. Changes are
shown relative to the original setting.
Example:
:ARR1 1 2 3 4 5 Set to 1 2 3 4 5
:ARR1 NUM 4 44 Change 4th value to 44, that is, change to 1 2 3 44 5
:ARR1 NUM 5 55 66 Change 5' to 55 66' (that is, change to 1 2 3 4 55 66)
No more values can be specified than are given by the UDA length (ULEN attribute). If more
values are entered, the excess ones are ignored and an error message is output.
An attribute may be returned to its default state by a command such as:
:ARR2 DEF
If no default exists, the UDA becomes unset. This always applies to REFERENCE, POS,
ORI and DIR UDA types since no defaults are allowed. REFERENCE UDAs may only
reference elements of the type given in the UDA definition.
2.6.2 Query UDAs in User Elements

Querying the attributes of an element will return the UDA name followed by its value(s). The
UDAs appear at the end of the attribute list, each UDA name being preceded by a colon.
UDAs can be queried individually by a command such as:
Q :UDA1
(the value(s) of the UDA will be returned).

For array UDAs, individual array values may be queried by commands such as:
Q :UDA [1] Query array value 1
The UDA definition may be queried using a command such as:
Q UDADEF :UDA1
The UDA name, length, description, minimum abbreviation length, defaults, units and list of
valid element types will be output.
2.6.3 Use of GOTO

It is possible to go to a UDA reference as with other references. For reference arrays the
command may be qualified by the NUMBER keyword. For example:
Example:
GOTO :REF2 [4} Go to the 4th reference in the list for UDA :REF2
2.6.4 Effect on UDA Instances if Definition is Changed

In all that follows it should be remembered that no change to a UDA instance (apart from
deletion of the UDA definition element) will occur until the COMPILE command has been
given in LEXICON.
Where an instance of a UDA exists, then changes to the definition may cause changes to
the instance.
If the UDA type (UTYPE attribute) is altered, the current instances will be inaccessible.
Unless UDA instances are purged (see next subsection), the process is reversible, that is,
resetting the type will re-enable access to the instances.
If the UDA length (ULEN attribute) is decreased, latter parts of numeric arrays or text strings
will become inaccessible. This process is reversible, that is, if ULEN is subsequently
increased, the values may again be accessed.
If an element type is removed from an ELELIST, instances of these element types will be
inaccessible. Again, this is reversible.
This indirect alteration of the apparent contents of the database could be disturbing for
users and it is recommended that the System Administrator should avoid modifying UDA
definitions once they are in use.
2.6.5 Purging UDA Instances

When a UDA definition is deleted, all instances of that UDA will appear to be lost from the
databases. However, the database space taken up by the UDA instances will not become
usable until the command:
PURGE UDAS
has been given from the user module. The space released is then recoverable when the
database is next compacted. Instances will not be PURGEd from locked elements.
Note: The PURGE command will operate on any UDA instance that it sees as being
invalid. This includes any UDA instance which is defined in a deferred LEXICON

database. Making the deferred database current will not result in the UDA instances
being recovered.
2.6.6 Expressions and Rules

Note: UDAs can be used in expressions and rules wherever an attribute is appropriate.
2.7 UDAs in Data Output Macros

All or part of a LEXICON database may be listed out using the OUTPUT facility. The
resulting macros may be read into LEXICON in the normal way.
As with other attributes, defaults will not appear in the output file unless the DEFAULT option
is selected.
When using OUTPUT with DESI, PADD or CATA databases that contain UDAs, the data file
will fail when read into a DESIGN/Drawing/CATALOGUE module if it contains UDA
instances whose definitions are not available on the target project or if the definition is
inconsistent with this instance.
2.8 UDAs in Project Reconfiguration

Project reconfiguration from ADMIN may be used in the normal way for transferring
LEXICON database data. After being reconfigured, the LEXICON database will be compiled
automatically. DESIGN databases do not need to be included in the update if a LEXICON
database is reconfigured. The normal use of reconfiguration to update projects is
unaffected; all UDA instances will be preserved. The space taken up by PURGED UDA
instances will be reclaimed.
2.9 Reference External Document

A UDAs can refer to an external document. Setting the UHYPER attribute on a UDA will
allow the user to launch the document (using the associated Microsoft Windows application)
from the Attribute Utility within the DESIGN Module.
During a LEXICON session create a UDA as follows:
Example:
NEW UDA /FILELINK UTYP Create a new Text UDA

TEXT
UDNA 'FILELINK' Make sure the length is enough to accommodate the file path
ULENGTH 50
UHYPER TRUE
ELE ADD EQUI STRU SUBS

PIPE ZONE SITE
Now switch to the DESIGN and from the command line type the following to set the UDA
value.

:FILELINK 'C:\TEST.XLS'
From the Attribute Utility in DESIGN it is now possible to right click the UDA and open the
file.

User Defined Element Types
3 User Defined Element Types
Within PDMS the standard set of elements are often used for a variety of purposes. A UDET
allows an element to be created with a more meaningful name, For example an
administrator could create clearly defined sub types such as Pipe Lagging, Pipe Painted
and Pipe Heated.
The hierarchy of elements which make up a UDET within the LEXICON database is shown
below.
UDETWL - (UDET World) is a top-level administrative element. As well as the standard

PDMS attributes, this has a DESC attribute which can contain up to 120 characters of text.
A UDETWL may hold UDETGR (UDET Group) elements or individual UDET (UDET
definition) elements. A UDETGR has the same attributes as a UDETWL.

3.1 UDET Attributes

UDETs have the following attributes:
BASETY The BASETY attribute indicates what system type the UDET is
derived from. The UDET will inherit only the core attributes of the
base type and not its UDAs.
UDNAME The name by which the UDET will be referred to in the PDMS
modules that use UDETs.
UDOLIST An array listing the allowed owner types within the Databases
hierarchy for example. Site, Zone.
UDMLIST An array listing the allowed member lists for example. NBOX,
NPOLYH.
UDHLIS An array listing the system attributes to hide when displaying a

UDET.
UDATLS Read-only Pseudo array containing a list of valid attributes.
3.2 Create a UDET Definition

The creation of a UDET has many similarities to the creation of a UDA covered in the
previous chapters of this document.
UDET definitions must be created in the dictionary database as members of a UDET group
(UDETGR) or as members of a UDET world (UDETWL).
Example:
NEW UDETWL /MYUDETWL1
NEW UDETGR /MYUDETGR1
NEW UDET /MYUDET Create new UDET
UDNA 'TESTUDET' Name the new UDET
BASETY EQUIP Base the new UDET on an equipment
As with UDAs, the UDNAME attribute is used to hold the UDET name. The name will then
be used for identification in the constructor modules.
Subsequently in constructor modules, elements of this type will be identified with a prefix
colon, for example.
:TESTUDET
The UDNAME name may be up to 50 characters long. Unlike UDAs there is no minimum
abbreviation.

A UDET must be based on any visible element type in the DESIGN, DRAFT, CATALOGUE
and Property DBs. The BASETY attribute indicates what system type the UDET is derived
from.
3.3 Redefine the Owner and Member List

When creating a UDET by default it will inherit the same allowed member types (UDMLIS)
and allowed owner types (UDOLIS) as it's base type. These lists may be reset.
The types in the new list must be either:
a system type allowed on the base type.
a UDET derived from a system type allowed on the base type.
Based on the previous example create a UDET named MYBOX based on a system type
BOX.
At the command line type 'Q UDLIST' to see the current owner list as follows:
EQUI STRU PTRA SUBE SUBS TMPL
At the command line type 'Q UDMLIST' to see the current member list as follows:
NBOX NPOLYH NCYL NSLC NSNO NDlS NCON NPYR NCTO NRTO NXTR NREV
Both lists may be completely redefined or the keywords 'ADD' or 'REMOVE' may be used to
add or remove particular entries.
The following example shows this functionality in a session:
Example:
UDOLIST SlTE ZONE Define SITE, ZONE as the only valid owners
UDOLIST ADD SlTE ZONE Add SITE, ZONE as valid owners
UDMLIST REMOVE ALL Remove all allowed member types
The allowed owner list and member list for a UDET may be any system types allowed on the
BASETY, plus any UDET based on these system types. In the example for :MYBOX the
user could not add a ZONE to UDOLIST, or an EQUI to UDMLIST because the system type
BOX of which the UDET is based does not allow this.
Another example would be a :MYBOX can only go under a SUBE, and that another UDET
named :MYNBOX can only go under :MYBOX or BOX and is achieved as follows:
For the :MYBOX UDET:
UDOLIST SUBE UDMLIST :MYNBOX
For the :MYNBOX UDET:
UDOLIST :MYBOX BOX
Changing the allowed owners/members for a UDET could invalidate some existing
instances. These are reported as warnings in DICE.

3.4 Hide System Attributes

The UHDLIS attribute is an array holding a list of system attributes to hide when displaying a
UDET. For example to hide iso-related attributes on a UDET:
UDHLIST BSTA HWRF TWRF BRLO RLSTOR TSFBR DELDSG
The ADD and REMOVE keyword can be used in association with UDHLIST.
3.5 Delete a UDET Definition

In a LEXICON session the DELETE command can be used to remove UDETs.
Object instances of this type will then no longer be recognized. They will default back to the
original system type. Any extra UDAs assigned to the UDET will also be deleted.
3.6 UDATLS Pseudo Attribute on a UDET

A read only pseudo attribute UDATLS can be queried, this will return a list of all valid
attributes for the UDET. In a LEXICON session navigate to a UDET and enter:
Q UDATLS
3.7 Presentation within the Constructor Modules and

ADMIN
The same command line instructions for system types are used when dealing with UDETs,
for example:
NEW :MYPUMP
DELETE :MYPUMP
Constructed names will be built up using the UDET for example BOX 1 of :PUMP 2.
UDETs may also be deleted by specifying their base type, for example the command
DELETE EQUl would delete either EQUl elements or UDETs based on EQUI.
Normally syntax which navigates the database must use the exact type. However navigation
syntax which traverse the database will allow a UDET to be matched against its base-type.
For example EQUl will also climb to a :PUMP based on EQUI. The following syntax is valid
for a UDET of type :PUMP, as well as explicit use of :PUMP:
BOX 1 OF EQUl
EQUl
A rule such as RPROP WTHK OF SCTN to work on a FITTING under a UDET based on a
SCTN can be allowed. However NEXT EQUl will not identify a UDET of type: PUMP.
3.8 Use of TYPE at the PML Level

The TYPE attribute returns the base-type, for example EQUI, for UDET. The attribute
ACTTYPE returns the derived type, if one. for example a :PUMP. The FULLTYPE attribute
returns the derived type such as EQUIPMENT or :PUMP. To get the Base full-type of an
element, the attribute FULSYS should be used.

The table below summarizes the functionality:
Base type Derived type
Full word, for example. EQUIPMENT FULSYS/TYPE FULL/TYPE
Short word, for example. EQUl TYPE ACTTYP/E
The attribute Query Q ATT (and the general attribute form) will include ACTTYPE as well as
type for UDET elements. ACTTYPE will be omitted if the element is not a UDET.
3.9 Collections and Expressions

Any attribute Query that takes an element type as a qualifier will take a UDET as a qualifier.
For example:
Q MCOUNT :PUMP
The number of :PUMPS in the current members list is returned.
Collections (and related expression syntax) will also work with UDETs.
For example:
collect all :PUMP for ISITEA.
Collecting on a type, will collect the derived types.
For example:
'COLLECT ALL EQUI'
will include :PUMPS as well as EQUI elements.
If just EQUI elements are required, excluding derived UDETS, they may be collected
explicitly using the syntax:
VAR !A COLLECT JUST EQU1 FOR IATEST
Applies to existing DRAFT selection rules, such as those for line-styles. The user should not
need to create new line-style definitions to cover any UDETs, unless they wish to distinguish
UDETs from their base elements.
Cursor syntax such as ID EQUI @ identify elements by their base type -thus :PUMP
elements will also be found. To exclude UDETs, the syntax ID JUST EQUI @ should be
used. If the 'JUST' keyword is used, it will apply to the entire list.
3.10 Change Type on an Instance

Where UDETs have the same base type or where the base types can be changed to one
another, then the UDET may be changed on an instance using the existing 'CHANGETYPE'
command. Any UDAs not valid on the new type will be lost.
For example currently BENDS can be changed to ELBOWS and vice versa.
Now define a :MYBEND based on a BEND and a :MYELBOW based on an ELBOW. An
instance of type :MYBEND, BEND,:MYELBOW or ELBOW can now be changed to any of
BEND, :BEND, ELBOW or :MYELBOW.

If the object has members which are of a type disallowed in the new type, then the switch
will be disallowed. Similarly it will be disallowed if the new type is not allowed as a member
of it's current owner.
3.11 Element UDET Check

A pseudo attribute UDETCHECK (UDETCH for short) is available for each element to
determine its UDET status. Some results from a 'QUERY UDETCHECK' command follows:
Not a UDET.
UDET : test defined by element /TestUdet in database TESTMDB/TESTDICT.
UDET definition for :TEST was lost.
UDET :test base type CONE does not match element type BOX.
3.12 Purge Report on MDB

In addition to element checking the 'PURGE REPORTS UDETS' command performs an
undirected UDET integrity check. The reports on any UDET integrity errors that appear in
the current MDB. Each element accessible from the WORLD element is checked for
consistency with the UDETs defined in the current MDB. Some example output from this
command follows:
/testelement1: UDET definition for :TEST was lost.
/testbox1: UDET :test base type CONE does not match element type BOX.
3.13 SPEC Selection

The SPEC question TYPE will allow a UDET.
Hence the first level of spec selection will take the UDET into account.
For example if a component is of type :MYLJSE, then the spec system will do the initial
selection on :MYLJSE. The spec might look as follows:
Example:
HEADING NAME TYPE PBOR0 SHOP DETAIL MATXT CMPREF BLTREF

DEFAULT
- - - =
*/20LJSE :MYLJSE 20.00 TRUE /DLJSE /MLJSE =0 /SB20

*/IOOLJSE :MYLJSE 100.00 TRUE /DLJSE /MLJSE =0 /SBl00
3.14 GTYP
Related to the SPEC selection, is the GTYPE. The GTYPE is held on the SCOMP. Normally
the GTYPE is the same as the TYPE of the design component, but it does not have to be.
Dabacon will report an error if it is not.
It is possible to set a GTYPE to a UDET. For example in PARAGON type:
GTYPE :MYLJSE
Dabacon will continue to check that the GTYPE on the catalogue component is the same as
the TYPE on the design component.


User System Defined Attributes
4 User System Defined Attributes
A USDA (User System Defined Attribute) allows the administrator to place a behaviour on a
standard PDMS element. For example limits may be applied to attributes of top level
elements within PDMS.
The hierarchy of elements which make up a USDA within the LEXICON database is shown
below.
A USDA allows the administrator to add the following behaviour to system attributes:
1. Set valid values
2. Define limits
3. Hide attributes on forms
4. Category.
The valid values and limits may be varied with element type.
These values are defined by creating a USDA element in the dictionary database. A USDA
element has the following attributes.
4.1 USDA Attributes

NAME - the name by which the USDA will be referred to in the PDMS modules.
DESC - is a text attribute which may be used to give a description of the USDA.

USYSTY - underlining system attribute to which the USDA is to be applied.

UALL - logical attribute, if set to true then the USDA will be applied to all PDMS elements
with the attribute defined in USYSTY.
ELEL - Array containing a list of PDMS elements to apply the USDA to.
UCAT - Allows the administrator to group USDAs on the attributes form within PDMS
modules, for example. UCAT MYCATAGORY.
If UCAT is left unset then it has no effect.
UHIDE Setting the logical attribute to True will indicate that the USDA will be hidden from
the Q ATT command and from the attribute form within PDMS. Querying of the individual
UDA will not be effected by this setting.
UTEAMS If the UHIDE attribute has been set then the UTEAMS attribute can be used to
indicate what teams the USDA will be available to. UTEAMS can hold an array of values.
4.2 USDA Limits and Valid Values

A USDA may own ULIMIT and UVALID elements to denote the limits and valid values.
These are described in Valid Values and Create a USDA.
4.3 Create a USDA

The following example will restrict the FUNC attribute on EQUIPMENT to be 'HeatX' or
'Pump', create a USDA as follows:
Example:
NEW UWRL /USDAWR
NEW UGRO /USDAGR
NEW USDA /UFUNC
DESC 'Set restriction on FUNC attribute on EQUI'
USYSTY FUNC
ELELIST ADD EQUI
NEW UVALID
UVVAL 'PUMP'
NEW UVALID
UVVAL 'HEATX'
To apply limits to a USDA the procedure is the same as UDAs. The following example will
apply limits to the POSSTART attribute on a STANCHION:

Example:
NEW USDA /LIMITSTAN
DESC Set limits on POSSTART attribute on SCTN
USYSTY POSSTART
ELYLIST ADD SCTN
NEW ULIMIT
UMIN 1000
UMAX 6000


Database Views
5 Database Views
The database views functionality provides the PDMS System Administrator the ability to
map element data into tables (Database Views) for a user workflow or report. A Database
View definition includes the criteria for selecting a set of elements from which the rows are
constructed. Each column in the Database View is then either an attribute value or
expression based on the row element or based on an element navigated to from the row
element. In this way each row may represent data from multiple data elements and multiple
database elements may be edited if a row of data is edited in a grid or via an import.
Database Views may be defined independently or grouped for use into Database View Sets.
Database View Sets are visible to the end user and provide a means of organising
Database Views for related workflows.
Due to the standard restrictions on data access while in the Lexicon module it is not
normally possible to display the results of the Database view definitions within the Lexicon
module. For this reason it is advised that Database Views are developed as User Views
(refer to Definition Sets) using the Database Views Editor in a module which has the
appropriate data access. The Database View once developed can then be copied into the
Dictionary database using the Database Views Editor.
5.1 Definition Sets

A Definition Set is a collection of Database Views defined in one place. By default the
definition sets are as follows:
Element Views Database Views provided for all Element Types within the
project schema. These are maintained as UDETs and
Distributed Attributes are edited and as UDAs are compiled.
Database View definitions in this definition set are not editable
but may be copied using the Database Views Editor as a basis
for customisation.
Project Views All Database Views defined within the Dictionary databases of
the project
User Views All Database Views defined by the user for independent use.
These are stored in an XML file in %PDMSUSER%.
Additional file based Definition Sets may be created and managed by the Database Views
Editor. Applications can also create their own definition sets.
Only Database Views within the Project Views Definition Set can be edited using the
commands described in this manual.

Database Views
5.2 Database View Elements and Attributes

The hierarchy of Database View definitions is as follows:
* Hierarchy is not complete and is expanded elsewhere on the diagram

+ Definition is recursive
DBVWWL is the top-level administrative element.

(Database View World)
DBVWGR is used to group definitions into manageable administrative

(Database View Group) sets, this is for administration only and is not visible to users
in other contexts.
DBVWSE is used to group Database Views for user presentation.

(Database View Set) These should contain related views as they are visible to the
user. A Database View can be a member of a Database View
Set even if it is not a direct member, refer to DBVW
Attributes.
DBVW is a table definition that defines the display name, element

(Database View) criteria and columns.
ATTFIL elements define attribute constraints that limit the rows in the
(Attribute Filter) table. An attribute filter is a test executed against the selected
element based on the value of a specified attribute such as
DESC Equals Vessel. A database element must match all
filters present in the Database View to be present in the
resulting table.

Database Views
EXPFIL is an expression that must evaluate to TRUE or FALSE to

(Expression Filter) determine whether a database element is part of the
database view. A database element must match all filters
present in the Database View to be present in the resulting
table.
ATTCOL elements define columns based on a single attribute.

(Attribute Column) Attributes may be system attributes or UDAs. Qualifiers can
be specified where required such as when accessing the
status of a particular element (refer to ATTCOL Attributes).
Columns based on attributes are by default editable but can
be made to be read only to help with workflow management.
EXPCOL elements define columns based on a PML or XPATH

(Expression Column) expression. Expression columns are read only unless
software is written to make them editable.
SRCELE elements define a navigational step from the current context

(Source Element) element to another database element. All columns defined in
the Source Element are then based on the element that
results from the navigation. Such columns are editable so
rows in Database Views allow editing of more than one
database element. Refer to Example Database Views for
example uses of Source Elements.
CRERUL define the rules for element creation. If within a DBVW

(Create Rules) element then the rules permit row creation for the Database
View provided that the AUTCRE attribute is set to TRUE.
Information such as where to create the new item or what
type of element to create can be fixed or specified using
expressions. Refer to LEXICON User Guide for how to use
parameters within expressions and how to prompt the user
for information.
SETPAR elements are used to define parameters for expressions in

(Set Parameter Rule) other create rules. A parameter can be used in expressions
on the CRERUL, SETATT or TESTEX elements. Parameters
provide the ability to prompt a user for a single piece of
information and then use it in multiple expressions.
SETATT rule defines a rule to set a database attribute when the

(Set Attribute Rule) element is created. This allows attributes to be defaulted at
the point of creation of forces a user/application to provide a
mandatory attribute value at the time of element creation.
SETSTA rules assign a status to the created item at the time of

(Set Status Rule) creation. This will help ensure all elements are being status
managed.
TESTEX if this evaluates to true then the owning rule will be carried
(Test Expression) out, otherwise the owning rule is ignored.
COLREL elements define Parent/Child relationships between columns

(Column Relation) for application use. These relationships are currently not
supported in the standard applications.

Database Views
5.2.1 DBVWSE Attributes

DBVWSE elements have the following attributes:
UDNA The user defined name for the Database View Set. This is the name
that is displayed to the user in applications where the View Sets are
shown.
DESC Description of the purpose or intended use of the Database View Set.
5.2.2 DBVW Attributes

DBVW elements have the following attributes:-
UDNA The user defined name for the Database View. This is the name that is
displayed to the user in applications. This will not be displayed if view
names clash.
DESC Description of the purpose of the Database View
ELEL The list of element types that are the basis for Database View rows. All
elements of the specified types will be present as rows as long as they
meet any criteria specified in EXPFIL or ATTFIL members of the
DBVW. The elements included in the view will include all UDETS
based on the listed types. For example if EQUI is in the ELEL attribute
and UDETs exist with a BASETY of EQUI then these will be present in
the view. To limit the view to not include UDETs a filter must be added
such as TYPE Equals EQUI
AUTCRE If new rows are allowed to be created by the view then set this to true.
The default is false which does not allow element creation.
DBVWST This is a list of Database View sets to add the Database View. If the
Database View is a member of a DBVWSE then it doesn't need to be
added to the list. This allows Database Views to be shared by
Database View Sets.
5.2.3 ATTFIL Attributes

ATTFIL elements have the following attributes:
DBATT The database attribute the filter is based on. This can be a system
attribute or a UDA. If setting to a UDA that has just been created or
named a COMPILE command may need to be run first.
FILTOP The operator for comparing the attribute value with FILTVA. This
includes the following operators:

Database Views
Equals
DoesNotEqual
LessThan
LessThanOrEqualTo
GreaterThan
GreaterThanOrEqualTo
Like
NotLike
MatchesRegularExpression
DoesNotMatch
StartsWith
DoesNotStartWith
Contains
DoesNotContain
EndsWith
DoesNotEndWith
InRange
InList
FILTVA The value to compare against the attribute value using the specified
operator.
5.2.4 EXPFIL Attributes

EXPFIL elements have the following attributes:
EXPR The expression to run to determine whether each element is in the

Database View or not. The expression must result in a logical (TRUE/
FALSE) value. The expression must be a valid PML 1 or XPath 1
expression. XPath expressions must be formed to match the xmlio
object output using the default copy stylesheet.
EXPTYP The syntax of the expression defined by EXPR. This is allowed to be

either PML or XPATH. If unset then PML is assumed.
5.2.5 ATTCOL Attributes

ATTCOL elements have the following attributes:
UDNA The user requested name for the column. If name clashes occur with
other columns defined in the Database View then (n) may be added
when displayed to the end of the requested name to provide a unique
name. If not provided then a unique name is derived using the
attribute referenced by DBATT.
DBATT The database attribute to access for the column value. This can be a
system attribute or a UDA. If setting to a UDA that has just been
created or named a COMPILE command may need to be run first.

Database Views
DESC The description for the column.
READ Set to TRUE if the column is to be read only, the default is FALSE.
This attribute does not need to be set for columns that reference read
only attributes such as REF.
ATQUAL This defines any additional qualifier to be passed when accessing the
attribute. This is required for some pseudo attributes such as STVVAL
and STVMOD.
5.2.6 EXPCOL Attributes

EXPCOL elements have the following attributes:
UDNA The user requested name for the column. If name clashes occur with
other columns defined in the Database View then (n) may be added
when displayed to the end of the requested name to provide a unique
name.
DESC The description for the column.
EXPR The expression to execute to get the column value. The expression
must be a valid PML 1 or XPath 1 expression. XPath expressions
must be formed to match the xmlio object output using the default
copy stylesheet.
EXPTYP The syntax of EXPR, this is either PML or XPATH. If unset PML is
assumed.
UTYP The data type of the column. If this is not set correctly an error will be
displayed. This must be one of INT, REAL, TEXT, REF, LOG, WORD,
POS, DIR or ORI. Array results are not supported by expression
columns.
5.2.7 SRCELE Attributes

SRCELE elements have the following attributes:
DESC Description for the data source identified by the SRCELE.
EXPR The expression that identifies a database element to navigate to from

the current context such as OWNER. The expression result must be
another element or for PML 1 expressions it can also be a text result
containing the name of the element to navigate to. XPath expressions
must be formed to match the xmlio object output using the default
copy stylesheet.

Database Views
EXPTYP The syntax of EXPR, this is either PML or XPATH. If unset PML is
assumed.
AUTCRE If true then elements can be created automatically if EXPR doesn't

return a valid element. An attempt is made to create the elements if
someone tries to set the value of a column within the SRCELE. The
creation is based on the rules defined by the CRERUL element
defined in the SRCELE.
5.2.8 CRERUL Attributes

CRERUL elements have the following attributes:
DESC Description for the rules.
OWNEXP Expression to define the owner where the element should be created.
If left unset the application is asked for input and then the user is
prompted. This expression may contain parameters defined by
SETPAR member elements. Any such parameters are substituted as
text into the expression before the expression is executed.
Parameters are substituted by prefixing the UDNA of the SETPAR
with $! For example : '/Equipment_$!Fluid' would substitute a
SETPAR with UDNA of Fluid.
OWNEXT The syntax of OWNEXP, this is either PML or XPATH. If unset PML is
assumed.
TYPEXP This must result in the name of the type of element to create. The
result of this expression must be of type TEXT such as ':LINETAG'.
Expression such as typename :LINETAG are not supported. This
expression may contain parameters defined by SETPAR member
elements. See OWNEXP for more details.
TYPEXT The syntax of OWNEXP, this is either PML or XPATH. If unset PML is
assumed.
CREANC This defaults to false and requires either OWNEXP, the calling
application or the user to provide the owner for the created element.
If set to true then this allows an owner to be 'found' or created for the
new element. This must only be used where the element hierarchy is
not significant.
5.2.9 SETPAR Attributes

SETPAR elements have the following attributes:
UDNA The name of the parameter as used in expression substitution.
UPROM The prompt to display to the user if information is requested.
DESC The description of the parameter.

Database Views
EXPR Expression allowing the value of the parameter to be derived. If left

unset the application and user are prompted for input. This must be a
PML 1 or XPath 1 expression.
EXPTYP The syntax of EXPR, either PML or XPATH. If left unset PML is
assumed.
UTYP The data type of the parameter. The parameter is always substituted
as a string into the target expressions but UTYP affects the
evaluation of EXPR and the way the user is prompted for a value.
This must be one of INT, REAL, TEXT, REF, LOG, WORD, POS, DIR
or ORI. Array types are not supported.
REQUIR Indicates that element creation can go ahead without a value for this
parameter.
5.2.10 SETATT Attributes

SETATT elements have the following attributes:
DBATT The database attribute to set at the point of creation. This can be a
system attribute or a UDA. If the UDA has itself just been created
then the COMPILE command must be run before this can be set to
refer to it.
UPROM The prompt to display to the user if no expression is given in EXPR.
EXPR An expression to derive a value for the new attribute. This can be a
PML 1 or XPATH 1 expression and may use parameter substitution
(See OWNEXP on CRERUL for more information on parameters). If
left unset the application and user are prompted for input.
assumed.
REQUIR Indicates whether element creation can proceed if no value is

specified for this attribute.
5.2.11 SETSTA Attributes

SETSTA elements have the following attributes:
STDEFR The status definition to assign to the created element at the time of
creation. If left unset the application and user are prompted for
input.
UPROM The text to display when the user is prompted for input.
REQUIR Indicates whether a valid status definition must be assigned for the
creation to complete successfully.

Database Views
5.2.12 TESTEX Attributes

TESTEX elements have the following attributes:
EXPR An expression resulting in a Boolean. If true then the containing rule

is used in the create process otherwise it is excluded from the create
process. The expressions can be a PML 1 or XPATH 1 expression
and may use parameter substitution (See OWNEXP on CRERUL for
more information on parameters).
assumed.
5.2.13 COLREL Attributes

COLREL elements have the following attributes:
UDNA The name of the relationship.
DESC A description of the relationship.
PARCOL The parent column that contains the super set of values.
CHDCOL The child column that contains the sub set of values.
5.3 Create a Database View Definition

The first step is to create a LEXICON database hierarchy, see Database View Elements and
Attributes. Commands used to create, delete and navigate around the LEXICON database
elements are exactly the same as those used for any other database type: refer to
Administrator Command Reference Manual for more details.
Example:
/*
NEW DBVWWLD /ProjectViews
NEW DBVWGROUP /ExampleGroup
NEW DBVW /ExampleVesselDBVW

UDNA 'ExampleVesselView'
ELEL EQUI
DESC 'View that contains only Vessels'
AUTCRE TRUE

Database Views
NEW ATTFIL /VesselFilter

DBATT DESC
FILTOP 'Equals'
FILTVA 'Vessel'
NEW ATTCOL
DBATT NAME
NEW ATTCOL
DBATT DESC
NEW ATTCOL
DBATT STVVAL
ATQUAL '/EquipmentStatus'
NEW CRERUL
OWNEXP '/Equipment'
TYPEXP |'EQUI'|
NEW SETATT
DBATT NAME
UPROM 'Vessel Tag'
NEW SETATT
DBATT DESC
EXPR |'Vessel'|
Note: The above example assumes that a status definition called /EquipmentStatus
already exists.

Database Views
5.4 Example Database Views
5.4.1 UDA Administration View : Real UDAs without Dimension

The following view contains a list of UDAs that have UTYPE set to REAL but have no
dimension assigned for unit of measure qualification.
Example:
NEW DBVW
UDNA 'UDAs : Reals without Dimension'
ELEL ADD UDA
NEW ATTFILTER
DBATTRIBUTE UTYP
FILTOPERATOR 'Equals'
FILTVALUE 'REAL'
END
NEW ATTFILTER
DBATTRIBUTE UUNI
FILTOPERATOR 'Equals'
FILTVALUE 'NONE'
END
NEW ATTCOLUMN
DBATTRIBUTE UDNA
END
NEW ATTCOLUMN
DBATTRIBUTE NAME
END
NEW ATTCOLUMN
DBATTRIBUTE OWNER
UDNA 'UGROUP'
READONLY true
END
END

Database Views
Since the Data content of this example is available from within LEXICON the results can be
seen immediately using the Database Views Editor.
5.4.2 Multi-element View : Schematic Equipment/Pipe Connectivity

The following view contains rows that show the connectivity between schematic Equipment
and schematic pipelines. This uses Source Elements to navigate from element to element.
All columns could be made writeable.
Example:
NEW DBVW
DESC 'Connectivity between schematic equipment and schematic
pipelines'
UDNA 'SCEQUI to SCPLINE connectivity'
ELEL ADD SCNOZZ
NEW ATTFILTER
DBATTRIBUTE CREF
FILTOPERATOR 'DoesNotEqual'
FILTVALUE 'Nulref'
END
NEW ATTCOLUMN
DBATTRIBUTE NAME
UDNA 'Nozzle'
READONLY true
END

Database Views
NEW SRCELEMENT
DESC 'Schematic Equipment'
EXPRESSION 'OWNER'
EXPTYPE 'PML'
NEW ATTCOLUMN
DBATTRIBUTE NAME
UDNA 'Equipment'
READONLY true
END
END
NEW SRCELEMENT
DESC 'Schematic Branch'
EXPRESSION 'CREF'
EXPTYPE 'PML'
NEW ATTCOLUMN
DBATTRIBUTE NAME
UDNA 'Branch'
READONLY true
END
NEW SRCELEMENT
DESC 'Schematic Pipeline'
EXPRESSION 'OWNER'
EXPTYPE 'PML'
NEW ATTCOLUMN
DBATTRIBUTE NAME
UDNA 'Pipeline'
READONLY true
END
END
END
END

Database Views
Since the data for this Database View is not available in LEXICON the Database View must
be shown by using the Database Views Editor or the Reporting interface in a schematic
module. A report is shown below that has been based on the view defined above.

Distributed Attributes
6 Distributed Attributes
For information on the use and definition of Distributed Attributes refer to the Database
Management Reference Manual.
6.1 Distributed Attribute Elements and Attributes

The hierarchy of Distributed Attribute definitions is as follows:
+ Definition is recursive
DSXWLD is the top-level administrative element.

(Distributed Attribute World)
DSXGRP is an administrative element that does not affect the

(Distributed Attribute Group) configuration of Distributed Attributes
DSXHOM element is the default home selector. The default home

(Default Home) configuration is defined by this elements members.
DSXDST denotes the default home value as a text string. It also

(Destination) contains a test that must have a true value for the
home to be valid.

DSXTST is a condition that must be met for member

(Test) destinations to be evaluated.
DSXSCH element is a container for related Distributed Attribute

(Distributed Attribute Schema) definitions that may share a DSXHOM for attribute
creation.
DSXOWN identifies the Binding Elements, this is the element

(Distributed Attribute Owner) types to extend with additional attributes.
DSXMBR identifies the Bound Elements, this is the element type

(Distributed Attribute Member) containing the attributes to add to the types listed in the
DSXOWN.
6.1.1 DSXDST Attributes

DSXDST elements have the following attributes:
DHTEST The test to evaluate to examine if this represents the

requested default home.
DHTEXT An expression of string or ID type that should evaluate to an

existing element at runtime. (For bound attributes, this must
resolve to a XPIWLD element).
6.1.2 DSXTST Attributes

DSXTST elements have the following attributes:
DHTEST The test to evaluate to examine if this represents the

requested default home.
6.1.3 DSXSCH Attributes

DSXSCH elements have the following attributes:
DEFHOM Identifies the default home selector for this schema if not
overridden by DEFHOM attributes on member elements.
The DEFHOM defines the location where the distributed
attributes are created and managed.
6.1.4 DSXOWN Attributes

DSXOWN elements have the following attributes:
DEFHOM Identifies the default home selector for this DSXOWN if not
overridden by DEFHOM attributes on member elements.
The DEFHOM defines the location where the distributed
attributes are created and managed.
ELEL The element types that are to be extended by the use of

distributed attributes

6.1.5 DSXMBR Attributes

DSXMBR elements have the following attributes:
AUTCRE If set to TRUE the bound element is automatically created if

it doesn't exist at a modification operation.
CARD This is the number of attribute elements allowed to be

bound to the Binding Element (Note, only the Max
Cardinality is currently effective).
DEFHOM Identifies the default home selector for the bound element
types defined in this definition. The DEFHOM defines the
location where the distributed attributes are created and
managed.
ELEL Defines the element types that represents the bound

attribute types. This is the element types containing the
attributes to add to the types listed in the DSXOWN


Status Definitions
7 Status Definitions
Status Control is the ability to control and report on the status of individual model objects as
they progress their lifecycles. It can be applied to any model objects, for example tagged
items, catalogue components, drawings etc.
The desired project configuration is created by administrators as Status Definitions in
LEXICON with the use of a hierarchy of Status World, Status Definition and Status Value
elements.
These elements can then be applied to model objects in any of the constructor modules -
Design, Paragon, Spooler, Diagrams, Draft.For more information on the creation of the
hierarchy, refer to Status Control.

Status Definitions

Command Syntax Diagrams
A Command Syntax Diagrams
The appendix contains the legal command and interrogation syntax diagrams relevant to the
PDMS LEXICON module. These diagrams formalise the precise command sequences
which may be used and are intended to supplement the explanations given in the
appropriate sections of this manual.
A.1 Conventions
The following conventions apply to the syntax diagrams in this appendix:
All diagrams have abbreviated names. Such names are composed of lowercase letters
enclosed in angled brackets, for example. <assign>. These short names, which are
used for cross-referencing purposes in the text and within other syntax diagrams, are
supplemented by fuller descriptions where they are not self-explanatory.
Commands to be input from the terminal are shown in a combination of uppercase and
lowercase letters. In general, these commands can be abbreviated; the capital letters
indicate the minimum permissible abbreviation.
Note: The convention does not mean that the second part of the command must be typed
in lowercase letters; commands may be entered in any combination of uppercase
and lowercase letters.
ELElist
may be input in any of the following forms:
ELE
ELEl
ELEli
ELElis
ELElist
Commands shown wholly in uppercase letters cannot be abbreviated.
Syntax diagrams are generally read from top left to bottom right.
Points marked with a plus sign (+) are option junctions which allows the user to input
any one of the commands to the right of the junction. Thus
>---+--- ABC -----.

| |
|--- PQR -----|
| |
|--- <dia> ---|
| |
-------------+--->
Type in ABC or PQR or any command allowed by the syntax given in diagram <dia> or just
press RETURN to get the default option.
Copyright 1974 to current year. A:1 12 Series

Points marked with an asterisk (*) are loop back junctions. Command options
following these may be repeated as required. Thus
.-------------.
/ |
>---*--- option1 ---|
| |
|--- option2 ---|
| |
--- option3 ---+-->
permits any combination of option1 and/or option2 and/or option3 to be used (where the
options may define commands, other syntax diagrams, or command arguments) and may
form an exception to the rule of reading from top left to bottom right.
The simplified format
.---------.
/ |
>---*--- name -+--->
Type in a list of PDMS names, separated by at least one space.
A.2 Command Arguments

These are inputs which are necessary to qualify command words. They are distinguished by
appearing in italics.
Name Definition Example

name PDMS element name /ABCDE
refno PDMS reference number =23/1403
integer a positive integer 0, 3
value signed number 3.142, -23.66, -34
word alphabetic word NULL, VALV (4 chars. max.)
text alphanumeric string Enclose Between Apostrophes
sign plus or minus character + (for ditto); - (in default lines)
equals equals character = (in default lines)
comma comma character 20, 40 (for range of values)
nl new line Press the RETURN key
Table A: 1. Examples of basic command arguments
A.3 Syntax Diagrams

Apart from the direct setting of UDA element attributes, the options for which are given in
User Defined Attributes, the only LEXICON commands are COMPILE (syntax COMPile),
ELELIST/REFLIST and COPY/KEYCOPY.

A.3.1 Compiling the Element List and Reference List

See User Defined Attributes.
A.3.2 <assign>
>--+-- ELElist --. .------------.
| | / |
-- REFlist --+-- ADD --+-- <eltype> --*-- <eltype> --|
| | |
| --------------+-->
|
-- REMove --+-- ALL -->
| .------------.
| / |
-- <eltype> --*-- <eltype> - |
| |
--------------+-->
<eltype> is any DESIGN, PADDLE, LEXICON, CATALOGUE or Specification element type:

see the appropriate user documentation for lists.
A.3.3 Copying a UDA

See Copy UDA Definitions.
A.3.4 <ucopy>
>--- KEYCopy --- <sgid> --->


Error Messages
B Error Messages
The appendix lists those error messages specific to LEXICON. All such messages have a
message number beginning with 68. Any other messages that may be output are not
described here as they are not specific to LEXICON.
Where messages are self-explanatory no description is included, but the error message is
listed for completeness.
(68:3) The REFLIST ADD command is only valid for a REFERENCE UDA
Added an element type to the Reflist of a UDA whose type is not

REFERENCE. Check the correct UDA is accessed, or reset the Utype
attribute, as appropriate.
(68:5) The element element_type is already in the ELELIST
Added an element type to the ELELIST that is already in the ELELIST.
(68:6) The element element_type is not in the ELELIST
Removed an element type from the ELELIST that is not in the ELELIST.
(68:7) The element element_type is already in the REFLIST
Added an element type to the REFLIST that is already in the REFLIST.
(68:8) The element element_type is not in the REFLIST
Removed an element type from the REFLIST that is not in the REFLIST.
(68:9) The current element type is not a UDA definition.
Modified the ELELIST (or REFLIST) of an element which does not have those
attributes.
(68:10) The ELELIST may only be 100 long.
(68:11) The REFLIST may only be 100 long.
(68:12) Maximum ABLEN is 20 characters.
(68:13) Maximum UDNAME length is 20 characters.
(68:14) The UDNAME may not contain a space.
(68:16) The ULEN must be between 1 and 120
(68:17) The UKEY is set by the system, and may not be set by the user
Copyright 1974 to current year. B:1 12 Series

Error Messages
(68:18) WARNING- The UDA definition is not REAL or INTEGER
Set DFLT to a real or integer value: can only do this for a UDA of the
corresponding type.
(68:19) WARNING- The default will only be used if the ULEN is set to 1
Set a UDA length (ULEN) which exceeds the length of the default UDA setting
(DFLT). Change ULEN (or DFLT).
(68:20) WARNING- The units will only be used if the UDA type is set to REAL or
INTEGER
Set units (UUNI attribute) for a UDA which is of type REAL or INTEGER.
Check that the correct UDA is selected or change UTYP, as appropriate.
(68:21) WARNING- ABLEN is greater than the length of UDNAME
Set the minimum abbreviation length of a UDA name to be greater than the
length of the UDA name itself. Reset ABLEN or UDNAME as appropriate.
(68:22) WARNING- The length of UDNAME is less than ABLEN
(See 68:21)
(68:24) WARNING- The UDA definition is not a LOGICAL type
Set DFLT to TRUE or FALSE for a UDA which is of type LOGICAL. Check the
correct UDA is selected or change UTYP, as appropriate.
(68:27) No valid keys remain for new UDA. Please compile dictionary and try
again
No more than 1000 keys may be used.
(68:28) WARNING- The UDA definition is not a TEXT type
Set DFLT to text for a UDA which is of type TEXT. Check the correct UDA is
selected or change UTYP, as appropriate.
(68:29) WARNING- The UDA definition is not a WORD type
Set DFLT to a word for a UDA which is of type WORD. Check the correct UDA
is selected or change UTYP, as appropriate.
(68:30) WARNING- the units text has been truncated to 20 long
Maximum length of text for the UUNI attribute is 20 characters.
(68:31) WARNING- BORE and DISTANCE units are only valid for REAL UDAs
Set UUNI to BORE or DIST for a UDA which is of type REAL. Check the
correct UDA is selected or change UTYP, as appropriate.
Note: The following messages will only occur following use of the COMPILE
command.
(68:61) Maximum number of definitions in the dictionary has been exceeded.
No more than 1000 definitions may be used.

Error Messages
(68:62) Two UDAs with different keys have the same name Udname. The second
definition will be ignored.
Two or more UDAs the same UDNAME.
(68:63) Two UDAs have the same key (integer) but different names or type. The
second definition Udname will be ignored
(68:64) Two UDAs with the same key/name (Udname) have the same element
(element _type) in their ELELISTs. Second UDA definition ignored.
(68:66) An attempt has been made to assign more UDAs than the maximum
limit of 100 to a single element type.
(68:67) WARNING for UDA name. The default is not applicable as the ULEN is
greater than 1.
(See 68:19)
(68:68) WARNING for UDA name. The default type does not correspond to the
UDA type. The default has been ignored
(68:69) WARNING for UDA name. The UUNIT attribute is not applicable unless a
REAL or INTEGER type. It has been ignored.
(68:70) WARNING for UDA name. The REFL attribute is not applicable unless a
REF type. It has been ignored
(68:71) UDA name has no name and has been ignored
The named element has no UDNAME.
(68:72) UDA name has no element list and has been ignored.
The ELELIST for the named UDA has no members.
(68:73) WARNING for UDA name. The ABLEN given is longer than the UDNAME.
A value of integer for ABLEN has been assumed
(68:74) Element type element type has more than 100 UDAs assigned to it.
Subsequent UDAs have been lost.
(68:75) The maximum number of definitions has been exceeded for the
dictionaries in the current MDB
Maximum number of definitions is 1000.
(68:76) WARNING for UDA name BORE, DISTANCE units are only applicable if a
REAL UDA type. The units have been ignored.
(68:77) UDA name has no Type set and has been ignored
The UTYPE attribute of the named UDA has not been set.
(68:78) WARNING for name. POS type UDAs must have DISTANCE units. DIST
units assumed.
(68:79) WARNING for name. POS,DIR,ORI types must have length of 1. Length of
one assumed.

Error Messages

Index
A L
Allowed Member List LEXICON Database . . . . . . . . . . . . . . . . 1:1
redefining . . . . . . . . . . . . . . . . . . . . . 3:3
assign . . . . . . . . . . . . . . . . . . . . . . . . . . . A:3 P
C Purge Report on MDB . . . . . . . . . . . . . . 3:6
Command Arguments . . . . . . . . . . . . . . . A:2 S

Command Syntax Diagrams . . . . . . . . . . A:1
Compiling SPEC Selection . . . . . . . . . . . . . . . . . . . 3:6
Element List Syntax Diagrams . . . . . . . . . . . . . . . . . . A:2
Reference List . . . . . . . . . . . . . . A:3 conventions . . . . . . . . . . . . . . . . . . . A:1
System Attributes
D hiding . . . . . . . . . . . . . . . . . . . . . . . . 3:4
Database Views . . . . . . . . . . . . . . . . . . . 5:1 T

Distributed Attribute Schema . . . . . . . . . 6:1
TYPE Attribute
E use of at the PML Level . . . . . . . . . . 3:4
Element UDET Check . . . . . . . . . . . . . . . 3:6 U

Error Messages . . . . . . . . . . . . . . . . . . . . B:1
ucopy . . . . . . . . . . . . . . . . . . . . . . . . . . . A:3
G UDA
Copying . . . . . . . . . . . . . . . . . . . . . . A:3
GOTO creating . . . . . . . . . . . . . . . . . . . . . . 2:7
use of . . . . . . . . . . . . . . . . . . . . . . . 2:14 UDA Attributes . . . . . . . . . . . . . . . . . . . . 2:2
GYTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:7 UDA Definitions
copying . . . . . . . . . . . . . . . . . . . . . . 2:7
I UDA Instances
effect of definition change . . . . . . . 2:14
Introduction . . . . . . . . . . . . . . . . . . . . . . . 1:1 purging . . . . . . . . . . . . . . . . . . . . . . 2:14
UDAs
Example . . . . . . . . . . . . . . . . . . . . . . 2:8
Copyright 1974 to current year. Index page 1 12 Series

handling in data output macros . . . 2:15

handling in project reconfiguration . 2:15
limits . . . . . . . . . . . . . . . . . . . . . . . . . 2:6
reference external document . . . . . 2:15
use in expressions . . . . . . . . . . . . . 2:15
use in rules . . . . . . . . . . . . . . . . . . . 2:15
valid values . . . . . . . . . . . . . . . . . . . . 2:5
UDAs in User Elements . . . . . . . . . . . . 2:12
querying . . . . . . . . . . . . . . . . . . . . . 2:13
setting . . . . . . . . . . . . . . . . . . . . . . . 2:13
setting and changing . . . . . . . . . . . 2:13
UDATLS Pseudo Attribute on a UDET . . 3:4
UDET Definition
creating . . . . . . . . . . . . . . . . . . . . . . . 3:2
deleting . . . . . . . . . . . . . . . . . . . . . . . 3:4
UDETs
attributes . . . . . . . . . . . . . . . . . . . . . . 3:2
changing type on an instance . . . . . . 3:5
collections . . . . . . . . . . . . . . . . . . . . . 3:5
expressions . . . . . . . . . . . . . . . . . . . 3:5
integrity check . . . . . . . . . . . . . . . . . 3:6
presentation within the Constructor Modules
3:4
UDETs, presentation within ADMIN . . . . 3:4
USDA
creating . . . . . . . . . . . . . . . . . . . . . . . 4:2
limits . . . . . . . . . . . . . . . . . . . . . . . . . 4:2
valid values . . . . . . . . . . . . . . . . . . . . 4:2
USDA Attributes . . . . . . . . . . . . . . . . . . . 4:1
User Defined Attributes . . . . . . . . . . . . . . 2:1
User Defined Element Types . . . . . . . . . 3:1
User System Defined Attributes . . . . . . . 4:1
Copyright 1974 to current year. Index page 2 12 Series


LEXICON Command Reference Manual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LEXICON Command Reference Manual

Uploaded by

Copyright:

Available Formats

LEXICON Command

Date Version Comments / Remarks

LEXICON Command Reference Manual

User Defined Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1

User Defined Element Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1

Copyright 1974 to current year. i 12 Series

UDET Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2

User System Defined Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1

Database Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:1

Copyright 1974 to current year. ii 12 Series

Create a Database View Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:9

Distributed Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1

Status Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1

Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B:1

Copyright 1974 to current year. iii 12 Series

Copyright 1974 to current year. iv 12 Series

1.1 LEXICON Database

Copyright 1974 to current year. 1:1 12 Series

Copyright 1974 to current year. 1:2 12 Series

2 User Defined Attributes

Copyright 1974 to current year. 2:1 12 Series

2.1 UDA Attributes

REAL Any numeric value, for example, 23.5

INTeger Any whole number, for example, 200

REFerence An element identifier, for example, /VESS1, =12/99

TEXT Any characters in closing single quotes.

WORD Any sequence of letters, for example, ABCD

LOGical TRUE or FALSE

POSition A position, for example, E10 N50 U100

DIRection A direction, for example, E 45 U

ORIentation An orientation, for example, U is E and N is D.

DATetime A datetime, for example 17 May 2012 18:00

Copyright 1974 to current year. 2:2 12 Series

ELElist ADD element_type

Elements must be removed from the list by using the syntax

ELElist REMove element_type...

ELELIST ADD ZONE add ZONE and PIPE elements

ELE REMOVE PIPE remove PIPE elements

ELE REM ALL remove all elements

Copyright 1974 to current year. 2:3 12 Series

REFLIST REM PIPE BRAN

REF REM ALL

REF REM PRIM

The REFLIST may have up to 100 members.

Values may also be input individually for example:

Copyright 1974 to current year. 2:4 12 Series

2.2 Valid Values and Valid Ranges

2.2.1 Valid Values

NEW UDA /STAT UTYP TEXT Create a new Text UDA

ELE ADD EQUI STRU SUBS PIPE ZONE

NEW UVALID /WARNING Create a UVALID element to hold a condition

UVVAL ' WARNING'

Copyright 1974 to current year. 2:5 12 Series

DESC 'Condition Warning'

/STAT Navigate back to UDA element

NEW UVALID /DANGER Create a second UVALID element

DESC 'Condition Danger'

NEW UVALID /CAUTION Create a third UVALID element

DESC 'Condition Caution'

NEW UDA /WEIG UTYP REAL

ELE ADD STRU SUBS EQUI Create UDA Weight

NEW ULIMIT Create a ULIMIT element beneath UDA

UMIN 5kg Set a minimum value of 5kg

UMAX 50kg Set a maximum value of 50kg