Draw allows design elements to be represented symbolically in a 2D View when the UPDATE Design command is executed. Symbolic representation can either replace or be in addition to the normal geometric representation of the elements.
Design symbols can consist of geometrical elements or text or can be a combination of both, including Draw Intelligent Text hash-codes. Design symbols can be scaled and oriented as required.
Graphic representation of design elements are controlled by Representation Rules. Refer to Representation Rules for further information.
The 2D symbols are generated from templates stored in the Draw database. These are the Symbol Templates (SYTM) and the Text Label Templates (TXTM), used for generation of geometric elements or text elements, respectively. Refer to Basic Hierarchy for a diagram of the Draw database hierarchy.
The data defining which templates to use for a given design element, and under which circumstances, is stored in the Catalogue database. Several templates can be associated with a design element so that it can be represented differently in different types of Views. The representation of a light fitting, for example, can depend on both the View direction (for example, plan or elevation) and the View classification (for example, Room Design or Cabling).
The design symbols are created as Design Symbol (DESSYM) database elements. DESSYM is a soft-type variant of the Special Label (SLAB) element. The DESSYM elements are added as members of a Design Symbol Layer (DSLAYE) element, which is a soft-type variant of the Layer (LAYE) element, and is therefore a member of a View. Only one occurrence of DSLAYE is created per View during the UPDATE Design process, the DSLAYE is removed if it subsequently ceases to own any child DESSYMs.
2D symbols are created as part of the annotation of the View, rather than design graphics. DSLAYEs and DESSYMs are created and deleted automatically by Draw, with no user control over these operations.
DESSYMs are not created for any design item whose origin falls outside the View rectangle or whose origin (or datum point) is excluded by the action of section planes.
Where only a symbolic representation is required (for example, when a normal geometric representation is not required in addition to design symbols), Draw does not attempt to determine whether the design items are hidden by the action of the Hidden Line Removal process.

Representation Rules
Basic Hierarchy
Draw
Design
Draw
Representation Rules
Representation Rules
Draw
Basic Hierarchy
Draw
Design
Draw
Draw


2D symbols can be specified as scaled or non-scaled. The size of a scaled symbol depends upon the View Scale (VSCA attribute of the View), and is therefore changed correspondingly when the View Scale changes (and after an UPDATE Design command). Non-scaled symbols are a fixed size, irrespective of View Scale and paper size. The Scaling Flag (SCALFG) of a design element has the value 1 when the design symbol can be scaled within a view and zero it is non-scaled.
For non-scaled design symbols which reference a symbol template (SYTM), the array elements of the XY scaling (XYSC) attribute of the design symbol are set equal to the NSIZE attribute of the referenced SYTM.
For a scaled design symbol which references an SYTM, the actual size on the sheet depends on the View Scale. The NSIZE attribute is used to scale the symbol to its actual size on the sheet and, by setting the array elements of the XYSC attribute equal to the VSCALE attribute of the View, this adjusts the symbol to the appropriate size for the View (uniform scaling).
Setting X and Y scaling factors of XYSC independently on the Design Symbol Link (DRSYLK) element enables non-uniform scaling of the design symbol. The design symbol (DESSYM) held in the PADD database can be scaled to the correct size for the design element that it is intended to replace in the Draw View, regardless of the aspect ratio of that design element.

scaled
non-scaled
Design
uniform scaling
non-uniform scaling
Draw


The correct orientation of a DESSYM in a Draw View is obtained by copying the value of the P-point Direction (PPDI) attribute from the Symbol Template (SYTM) or Text Label Template (TXTM) to the PPDI attribute of the DESSYM. The 2D Symbology functionality to uses the direction of the P-point, which is determined by the P-point direction (PTCD) attribute on the P-point element, to align the X-axis of the SYTM or TXTM.
SYTMs and TXTMs are created and modified in Draw Administration Mode. In addition the administrator must associate the SYTM and TXTM with orientation of the component in the Catalogue that the DESSYM represents. You can either select an existing P-point on the Catalogue component, or create a new P-point. Then the value of the PPDI attribute on the SYTM or TXTM is set to the value of the P-point Number (%NUM) attribute on the Catalogue component.

Draw
Draw


You can query which Design elements are visible in a specified Draw View using the Q VSCAN command. For example:
The IN view_id can be omitted if your current database position is at or below a View.
You can:
In the examples, design_id must refer to a Design significant element, which is EQUI, SUBE, STRU, SUBS, FRMW, SBFR, TMPL, BRAN, or HANG.
Draw determines whether design items are visible by scanning the data in the picture, not by scanning the IDList. Thus elements hidden by the hidden-line-removal process are not found. The command cannot determine how much of the element is visible.
Q VSCAN <SIGNIFICANT | design_id> <IN view_id> <FOR selection_criteria>

Request a list of all significant elements that are visible in a View.
Q VSCAN SIGNIFicant IN view_id
For example:
Q VSCAN SIGNIF IN /VIEW-01
Specify a significant design element and request a list of all its primitives that are visible in a View.
Q VSCAN design_id IN view_id
For example:
Q VSCAN /PIPE100-B-1-B1
Specify selection criteria to determine matching design elements visible in a View.
Q VSCAN IN view_id FOR selection_criteria
For example:
Q VSCAN FOR ALL (VALVE VTWAY VFWAY) WITH (ABOR GE 50)
Q VSCAN FOR SCTN EXCL WITHIN E 800mm N 750mm U 638mm To E 900mm N 850mm U 738mm
Request a list of all significant elements that are visible in a View.
Q VSCAN SIGNIFicant IN view_id
For example:
Q VSCAN SIGNIF IN /VIEW-01
Request a list of all significant elements that are visible in a View.
Specify a significant design element and request a list of all its primitives that are visible in a View.
Q VSCAN design_id IN view_id
For example:
Q VSCAN /PIPE100-B-1-B1
Specify a significant design element and request a list of all its primitives that are visible in a View.
Specify selection criteria to determine matching design elements visible in a View.
Q VSCAN IN view_id FOR selection_criteria
For example:
Q VSCAN FOR ALL (VALVE VTWAY VFWAY) WITH (ABOR GE 50)
Q VSCAN FOR SCTN EXCL WITHIN E 800mm N 750mm U 638mm To E 900mm N 850mm U 738mm
Specify selection criteria to determine matching design elements visible in a View.
Note: It is possible but not recommended to enter the syntax:
Q VSCAN FOR SCTN WITHIN <volume> IN CE
In this case the "IN forms part of the generic selection criteria syntax (equivalent to "WRT CE") and is unlikely to be what is intended. The results may be very different from the probable intent of syntax, for example:
Q VSCAN IN CE FOR SCTN WITHIN <volume>
Note: A significant Design element is not found in a View if it only owns other significant elements. It must own visible primitives. The EQUI, STRU and FRMW elements are affected; they are not found unless they own visible primitives.

Draw
Q VSCAN

view_id
Q VSCAN SIGNIFicant IN
view_id
Q VSCAN SIGNIF IN /VIEW-01
Q VSCAN
design_id
 IN
view_id
Q VSCAN /PIPE100-B-1-B1
Q VSCAN IN
view_id
 FOR
selection_criteria
Q VSCAN FOR ALL (VALVE VTWAY VFWAY) WITH (ABOR GE 50)

design_id
Note
:
Q VSCAN FOR SCTN WITHIN <volume> IN CE
Q VSCAN IN CE FOR SCTN WITHIN <volume>
Draw
Note
:


You can query whether low-level design elements and their owners display in a given View using the command:
where gid is the general identifier of the element and view is the view identifier. For example:
The view identifier can be omitted if it is the current element. For example:
Possible answers are:
Q FIND /BOX99 IN /SH1/V1
Q FIND /VESS-05 IN VIEW
Q FIND ILEAVE TUBE OF /VALVE-24 IN /VIEW/02
Q FIND /BRANCH-01
FOUND
MISSING
INVALID ELEMENT
Note: A significant Design element is not found in a View if it only owns other significant elements. It must own visible primitives. The EQUI, STRU and FRMW elements are affected; they are not found unless they own visible primitives.

Q FIND
gid
 IN
view
gid
view
Note
:


You can query the nearest side of a View to a given P-point, proportional distance along a P-line, or origin of a Design element in the current View using the command:
For example:
The ROTATED option allows the rotation (for example, the VIEW’s RCOD attribute) to be considered if required.
The response is the nearest and next-nearest sides, and also whether the item is inside or outside the View. For example, Point 1 is LEFT UP OUTSIDE.

Q VSIDE OF /VESS-99
Q VSIDE OF PPO2 OF /VALVE-100
Q VSIDE OF PPLINE TOS OF /SCTN-101 START
Q VSIDE OF PPLINE MEML OF /SCTN-101 PROP 0.5

Q VSIDE [ROTated] OF
 3d_point_definition


Keywords
HIGHLIGHT UNHIGHLIGHT SOLELY IN
Description
This facility lets you highlight elements on a sheet.
The SOLELY keyword clears all previous highlighting before highlighting the defined components.
Design geometry must be highlighted in a specific view. This defaults to the current owner but can be overridden with the IN keyword.
HIGHLIGHT CE
Highlight the current element in the current view.
HIGHLIGHT IN /VIEW1 EQUI1
Highlight EQUI1 in VIEW1.
HIGHLIGHT SOLELY CE ALL STRA
Highlight only the current element and all STRA components.
UNHIGHLIGHT
Clear highlight on all elements.
HIGHLIGHT CE
Highlight the current element in the current view.
HIGHLIGHT IN /VIEW1 EQUI1
Highlight EQUI1 in VIEW1.
HIGHLIGHT SOLELY CE ALL STRA
Highlight only the current element and all STRA components.
UNHIGHLIGHT
Clear highlight on all elements.
Command Syntax
HIGHLIGHT CE
Highlight the current element in the current view.
HIGHLIGHT IN /VIEW1 EQUI1
Highlight EQUI1 in VIEW1.
HIGHLIGHT SOLELY CE ALL STRA
Highlight only the current element and all STRA components.
UNHIGHLIGHT
Clear highlight on all elements.

Keywords
Description
Examples
HIGHLIGHT CE
HIGHLIGHT IN /VIEW1 EQUI1
HIGHLIGHT SOLELY CE ALL STRA
UNHIGHLIGHT
Command Syntax
>-- HIGHLIGHT --+- IN <gid> -.
                |            |
                ‘------------+- SOLELY -.              .------<-------.
                             |          |              |              |
                             ‘----------+-- <selatt> --+-- <selatt> --+-->
>-- UNHIGHLIGHT --+------<-------.
                  |              |
                  ‘-- <selatt> --+-->


This chapter explains the concept of Design Templates, which lets the user create and store standard design configurations for subsequent use, and the Design Datasets which hold the parameterized data settings for such templates.


A design template is a set of design primitives, panels and nozzles that may be grouped together and then referenced from within another part of the Design database as though it were a single item. In many ways, a design template behaves in a similar way to a Catalog component, except that the template items are stored in a special area of the Design DB, rather than in a separate Catalog Database (DB), and they can use the more powerful sets of primitives and parameterization facilities available from within Model. Unlike a Catalog component, a design template can be split down into its constituent parts for selective reporting, dimensioning, MTO, etc.
A design template is used in a design by creating an instance of the template. When a design template is instanced, the template contents are copied into the Design hierarchy and a reference is set to the original template definition. At this release version, a design template may only be copied under a Panel Fitting, a Section Fitting or a Primary Joint. A design element cannot own more than one design template, nor can one design template own another template.
Design templates may be parameterized to allow a single template definition to be used in different circumstances. The parameterization facilities use Design Datasets to store named parameters, which may then be referenced in geometric and p-point definitions. The value assigned to a parameter can be defined in terms of a rule by using any of the standard expression syntax.
Note:
The definition of Design Templates is likely to be done by the person who organizes Catalog and Specification data in a company, while the use of Design Templates for building up a design model will be carried out by a Plant designer. Therefore, although both functions are carried out in Model, this chapter is relevant to two different types of user.

instance
Note
:


Design Template (TMPL) elements are usually stored in a separate Design DB under an administrative Template World (TPWL) , which is itself divided into administrative Template Areas (TMAR) .
Each TMPL is initially created as a copy of an existing set of design elements which have been created in a part of the usual hierarchy below a SITE. The TMPL may then be modified by the addition of positive and/or negative primitives, negative extrusions, etc. For example, a very simple template, consisting of a positive box and a negative box, could be created thus:

When this template is instanced in a design model, say under a panel fitting, its constituent elements are copied back and all parameterization rules are executed so that the attributes of the copy are set to suit the local Model requirements, thus:

All attributes of the copy are locked to prevent unintentional changes.

Design Template
Template World
Template Areas


Control of Negative Primitive Application

Negatives owned by positive primitives directly under a Template, or deeper in the component hierarchy behave as normal design primitives in that they are removed from their owner's geometry to create holes and notches.
A Template can also directly own negatives, which, in isolation, have nothing to be applied to. These negatives act in the same way as negatives within Negative Geometry sets in the Catalog database. Together these apply to the template geometry as a whole, or the geometry of other associated items in the context of the element whose geometry is defined by the template. For example a joint can be defined by a Catalog item, or a template, and both need to be able to modify the geometry of an attached section element (SCTN or GENSEC) and/or the geometry of the beam element on which the joint has been welded or bolted.
To determine the behaviour of these negative geometry elements each has a Negative Application attribute (NAPP). Refer to Negative Geometry Sets in the Catalog and Specification Reference manual for further information.
Key values of NAPP are:
0
Negative Primitive will not be removed from anything.
1
Negative Primitive will be removed from the item Attached to the owner of the Template geometry. The template user will be a joint type element (SJOI,SUBJ,FIXING etc), and the attached elements will be either a SCTN or a GENSEC
2
Negative Primitive will be removed from its 'significant' Owner or hierarchical owner. The template user will be a Fitting (FITT, PFIT, FIXING, SBFI etc.) and the hierarchical owner will be a PANEL, SCTN or GENSEC.
4
Negative Primitive will be removed from the item using the Template itself. This item could be any type of element. In the case of FIXINGs subsidiary to other fixings, both the subsidiary and owning compound fixing will be operated on as the item itself.
0
Negative Primitive will not be removed from anything.
1
Negative Primitive will be removed from the item Attached to the owner of the Template geometry. The template user will be a joint type element (SJOI,SUBJ,FIXING etc), and the attached elements will be either a SCTN or a GENSEC
2
Negative Primitive will be removed from its 'significant' Owner or hierarchical owner. The template user will be a Fitting (FITT, PFIT, FIXING, SBFI etc.) and the hierarchical owner will be a PANEL, SCTN or GENSEC.
4
Negative Primitive will be removed from the item using the Template itself. This item could be any type of element. In the case of FIXINGs subsidiary to other fixings, both the subsidiary and owning compound fixing will be operated on as the item itself.
Other values of NAPP are allowed and will be additions of 1, 2 and 4 to allow the negative primitive to operate on any combination of attached, owner and itself.
0
Negative Primitive will not be removed from anything.
1
Negative Primitive will be removed from the item Attached to the owner of the Template geometry. The template user will be a joint type element (SJOI,SUBJ,FIXING etc), and the attached elements will be either a SCTN or a GENSEC
2
Negative Primitive will be removed from its 'significant' Owner or hierarchical owner. The template user will be a Fitting (FITT, PFIT, FIXING, SBFI etc.) and the hierarchical owner will be a PANEL, SCTN or GENSEC.
4
Negative Primitive will be removed from the item using the Template itself. This item could be any type of element. In the case of FIXINGs subsidiary to other fixings, both the subsidiary and owning compound fixing will be operated on as the item itself.


Application Data Areas and Elements are a new form of definition in the Design Database that are provided to assist Appware Applications to store model parts for copying and propagation within a design. They have some similarities with Templates, but are more general in content, and more restrictive in behaviour.
Application Data Areas and Elements are expected to be used for Piping Assemblies and Platforms Stairs and Ladders (PSL) applications and perhaps others. They are also expected to be used for storing Supports definitions to make the management of these more robust.
The Elements available are administrative elements allowing applications to organize data storage areas of design objects that are not part of the design itself, but supplementary objects used to create and maintain the model. They will not be accessed (unless specifically instructed to do so) when performing model queries such as clashing, mass properties, collections etc. They are similar to Catalog definitions and to Template definitions in particular.
The top level element in the Model database is Design WORL. This owns a top level application data element
APPLDWorld
- Application Data World
APPLDW can own
APPDAReas
- Application Data Areas
DDAR
- Design Data Set Areas
APPLDWorld
- Application Data World

APPLDW can own

APPDAReas
- Application Data Areas

DDAR
- Design Data Set Areas
DDARs are existing element types. They own Design Data Sets (DDSE) for storage of data used by Template expressions and Rules, and by Appware. They can be used for Appware to store data, rules, etc for use in data driven instancing of assemblies.
APPDAR can own:
APPLDAta - Application Data. This is logically similar to a Template Definition.
APPLDA is a new element type. It can own
ZONE
DDSE
- Design Dataset
DPSE
- Design Pointset
ROOM
APPDAR can own:

APPLDAta - Application Data. This is logically similar to a Template Definition.

APPLDA is a new element type. It can own

ZONE

DDSE
- Design Dataset

DPSE
- Design Pointset

ROOM

The following diagram illustrates the relative positions of these elements in the Model database hierarchy:

APPLDWorld
- Application Data World
APPLDW can own
APPDAReas
- Application Data Areas
DDAR
- Design Data Set Areas
APPDAR can own:
APPLDAta - Application Data. This is logically similar to a Template Definition.
APPLDA is a new element type. It can own
ZONE
DDSE
- Design Dataset
DPSE
- Design Pointset
ROOM

APPLDWorld
APPLDAta


Everything under the Application Data World (APPLDWorld) is treated in the same way that hierarchies under Template Worlds (TMWL) are. In particular, Clash checking on command, spatial mapping and auto clashing will be isolated from normal design data except when specifically queried within the APPLDWorld.


Names in the APPLDWorld are in the same scope as the normal project model and so duplicate names will clash. This is not likely to be an issue as it is expected that application data will be unnamed. It would become an issue if sections of 'real' model data are copied or included (moved) into the APPLDWorld.
APPLDA elements have a local name scope so that objects that the APPLDA owns can have local names, allowing any Appware manager that manipulates Application Data to easily identify elements within them in the same way that design templates (TMPLates) are handled. Existing commands and expression functions such as LNAME, LNID etc operate within this scope.


A template (TMPLate) can be included in the Application Data World, but only as an instanced template, NOT a template definition. Such templates can be refreshed from their definitions using existing (appware and core) driven functions. However, there is no core supported means to refresh copies of Application Data in the real model.


DDAT elements have a new attribute PTOLER that provides a tolerance value as an alternative to the MAXMIN values which determine the range of valid values when set. Applications using the Application Data will use this value to validate its data.


Valid Value Elements Additional Attribute

Valid Value elements (VVALUE) owned by a DDAT can have a Valid Rule set stored in the attribute VALRULE. VALRULE is an expression attribute that can store an expression that evaluates to a logical true or false value. If the expression does not evaluate to a logical result, or if there are errors in the evaluation of the expression, then the VALRULE will return FALSE when queried. The VVALUE element owns a Valid Value attribute (VALIDV) that is an expression returning a real, logical, text or reference value which supports the owning DDAT element. If the VALRULE is true, or if it is a null expression, then this VALIDV will be available to the DDAT.
VALRULEs are used by the system to control the choice of a Valid Value when property queries are made on the owning DDAT.
For example a DDAT element might own four VVALUE elements with VALIDV and VALRULE attributes as follows:
VVALUE 1
( ID /ANG35x35x15 )
( LDPR LENG le 1800 )
VVALUE 2
( ID /ANG40x40x15 )
( LDPR LENG gt 1800 and LDPR LENG le 2400 )
VVALUE 3
( ID /ANG45x45x18 )
( LDPR LENG gt 2400 and LDPR LENG le 3000 )
VVALUE 4
( ID /ANG50x50x18 )
( LDPR LENG gt 3000 )
The current set of VALIDValues available for the owning DDAT are the set whose VALRULEs either are unset, or evaluate to TRUE. Those that are not available are those whose VALRULEs either evaluate to FALSE, or whose evaluation generate errors.
VValue
VALIDValue expression
VALRULE expression
VVALUE 1
( ID /ANG35x35x15 )
( LDPR LENG le 1800 )
VVALUE 2
( ID /ANG40x40x15 )
( LDPR LENG gt 1800 and LDPR LENG le 2400 )
VVALUE 3
( ID /ANG45x45x18 )
( LDPR LENG gt 2400 and LDPR LENG le 3000 )
VVALUE 4
( ID /ANG50x50x18 )
( LDPR LENG gt 3000 )


Extension to Design Data Associated Pseudo Attributes

Local Design Data Set (DDSE) pseudo attributes DEPL, LDPR, DEPR, DEPD and LFDP (which up to release 12 only operated within the scope of the owner of a DDSE) now also operate at the DDSE level and within the scope of a DDSE:
DEPL
List of
Property keys
Properties in all
owned DDSE
Properties in this
DDSE
Properties in owning
DDSE
LDPR
Real value
Property in any owned DDSE
Property or
Default Property
in any DDSE
owned by owner
of DDSE
Property in any
DDSE owned by
owner of owning
DDSE
DEPR
Text value for text and reals

LFDP
Reference value

DEPD
Text default
value for text
and reals
Default Property
in any owned
DDSE

Default Property in any DDSE owned by owner of DDSE
All attributes fail above the owner of the DDSE.
Attribute
Returns
At Owner of DDSE
At DDSE
Below a DDSE
(DDAT, VVALUE etc)
DEPL
List of
Property keys
Properties in all
owned DDSE
Properties in this
DDSE
Properties in owning
DDSE
LDPR
Real value
Property in any owned DDSE
Property or
Default Property
in any DDSE
owned by owner
of DDSE
Property in any
DDSE owned by
owner of owning
DDSE
DEPR
Text value for text and reals
LFDP
Reference value
DEPD
Text default
value for text
and reals
Default Property
in any owned
DDSE
Default Property in any DDSE owned by owner of DDSE


Special Design Data Property names in scope of a DDSE

Each of the Local Design Data pseudo attributes DEPL, LDPR, DEPR, DEPD and LFDP take a qualifier that is the key to a particular design data element (the DKEY of the DDAT). Special values of this key are used to query values within the DDAT and VVALUE elements:
VALI:
for returning evaluation of the VALIDV attribute of a VVALUE
VALR:
for returning the evaluation of a VALRUL attribute of a VVALUE
VVAL:
for returning a VALIDV/ALUE result with a true VALRULE
DDAT:
for returning the value of the local DDAT (either a DPROPerty or else a DDEFAUlt without knowing its DKEY
VALI:
for returning evaluation of the VALIDV attribute of a VVALUE
VALR:
for returning the evaluation of a VALRUL attribute of a VVALUE
VVAL:
for returning a VALIDV/ALUE result with a true VALRULE
DDAT:
for returning the value of the local DDAT (either a DPROPerty or else a DDEFAUlt without knowing its DKEY
VALR
ERROR, no VALRUL attribute
result of evaluated VALRUL attribute
VALI
ERROR, no VALIDV attribute
result of evaluated VALIDV attribute
VVAL
returns VVAL result of first VVALUE element that does not ERROR,
returns result of evaluated VALIDV if VALRUL evaluates TRUE, else ERROR
DDAT
returns the same value as would be returned using the DKEY of the DDAT. (Either the DPROPerty or DDEFAUlt value). This is a convenient way of obtaining this value without knowing the DKEY
Returns the same value as the DDAT property of the owning DDAT without having to know the actual DKEY value to use.
All of these properties will error if queried at the DDSE element or above.
If the Design Data set actually has a data element that has a property with one of these name keys (they are not reserved in anyway) then the use of the key will operate normally on the DDSE or its owner, and as listed in the table above on a DDAT or VVALUE.
Use of the VVAL key on a particular DDAT will return the first suitable value from a set of many values. This is similar to choosing from a set of values according to some criteria. It is possible to use this as an alternative to the IFTRUE expression, which can, for example when used iteratively, select a set of possible choices depending on a particular criterion. The IFTRUE expressions will increase the expression length with the possibility of exceeding the maximum length of the text attribute. Use of VVAL key will not do this.
The VVALUEs owned by a DDAT DO NOT modify the return values of design data properties when queried by their owners.
It should be noted that if the DPROPerty of a DDAT is inconsistent with the set of VVALUEs that it owns, this will NOT raise an exception or error when querying it directly using its DKEY. It is up to the application using these data values to decide whether to accept the value of a DPROPerty whenever it conflicts with valid values, or maximum or minimum values, or a tolerance. To do otherwise would risk the integrity of existing user and system applications.
VALI:
for returning evaluation of the VALIDV attribute of a VVALUE
VALR:
for returning the evaluation of a VALRUL attribute of a VVALUE
VVAL:
for returning a VALIDV/ALUE result with a true VALRULE
DDAT:
for returning the value of the local DDAT (either a DPROPerty or else a DDEFAUlt without knowing its DKEY
element special key word
DDAT
VVALUE
VALR
ERROR, no VALRUL attribute
result of evaluated VALRUL attribute
VALI
ERROR, no VALIDV attribute
result of evaluated VALIDV attribute
VVAL
returns VVAL result of first VVALUE element that does not ERROR,
returns result of evaluated VALIDV if VALRUL evaluates TRUE, else ERROR
DDAT
returns the same value as would be returned using the DKEY of the DDAT. (Either the DPROPerty or DDEFAUlt value). This is a convenient way of obtaining this value without knowing the DKEY
Returns the same value as the DDAT property of the owning DDAT without having to know the actual DKEY value to use.


Design Datasets (DDSE) are used to store the properties of design template items, which may then be used to define the template’s parameters.
Each property is stored in a Design Data (DDAT) element under a DDSE, with each DDAT being identified (and subsequently referenced) by a keyword or property name by a keyword held in its DKEY attribute.
The property definition can be specified by an expression held in the Design Data Property (DDPR) attribute, while a default value or expression for the property (which is used if the DDPR expression cannot be evaluated for any reason) can be stored in the Design Data Default (DDDF) attribute.
Unlike a design reference to a Catalog component, which can access only a single Catalog dataset via its DTREF setting, a reference to a design template can access more than one design dataset.
The following diagram illustrates the relative positions of these types of dataset for a simple hierarchy:

The pseudo‑attributes available for accessing the properties data in the various types of dataset are as follows:

Most commonly, a design attribute value will be defined in terms of a design property by using the Current Design Dataset Property (CDPR) attribute. The CDPR can also be used to define a property in one dataset in terms of a property in another dataset. When a CDPR is used in a rule for a component whose owner can own datasets, the current datasets will be those at the same level as the component: otherwise, the current datasets will be those under the first dataset-owning element above the component. When a CDPR is used in a property expression within a dataset, it refers to a property in the current dataset for the item at which CDPR is evaluated.
When used in a querying command or in an expression (for example, when defining a parameterization rule), the attributes for a specific property are identified by the DKEY for that property. For example:
Q CDPL
Lists all DKEYs for properties in current dataset.
Q CDPR LENG
Gives value of LENG property in current dataset.
RULE SET XLEN (CDPR LENG)
Sets rule for current element’s XLEN attribute using value from LENG property in current dataset.
Q CDPL
Lists all DKEYs for properties in current dataset.
Q CDPR LENG
Gives value of LENG property in current dataset.
RULE SET XLEN (CDPR LENG)
Sets rule for current element’s XLEN attribute using value from LENG property in current dataset.
Q CDPL
Lists all DKEYs for properties in current dataset.
Q CDPR LENG
Gives value of LENG property in current dataset.
RULE SET XLEN (CDPR LENG)
Sets rule for current element’s XLEN attribute using value from LENG property in current dataset.
A local design dataset is owned directly by the current element,
A template design dataset is owned by the first template below the current element, and
A current design dataset is at the same level as the current element and has the same owner.
A local design dataset is owned directly by the current element,
A local design dataset is owned directly by the current element,
A template design dataset is owned by the first template below the current element, and
A template design dataset is owned by the first template below the current element, and
A current design dataset is at the same level as the current element and has the same owner.
A current design dataset is at the same level as the current element and has the same owner.
Note:
The dataset attributes PRLS, PROP and PRDE are also used to refer to Catalog dataset properties. To query any of these attributes, a search for a Catalog dataset will be made first; if this fails, a search for a design template dataset will be made.
Note:
Usually default values are assigned to properties, which are then used to evaluate expressions during the creation of a design template. Which allows the user to see the template geometry in a graphical view, at a practical scale, as defined. Thus a default value for LENG in the last example would allow a sensible XLEN dimension to be evaluated from the rule for display purposes. When instanced in a design, the value of the LENG property would be derived from, say, a design parameter and the rule would be re‑executed to give the correct XLEN.

Design Datasets
Design Data
DKEY

DDPR
DDDF
A local design dataset
A
template design dataset
A current design dataset
Note
:
Q CDPL
Q CDPR LENG
RULE SET XLEN (CDPR LENG)
Note
:


The data property can return
and the DDPR expression should evaluate to one of these values. So should the DDDF and VALIDV attributes of any owned VVALUE of the property (DDAT).
Whichever type of value is expected is determined by the pseudo attribute used to access the data property. There are different attributes for each type, and for each of local, template, or current design properties as is described below.
The PTYP attribute of the DDAT element can be set to a WORD value (4-6 uppercase alphabetic characters) to signify the type of data stored or evaluated in the property. For text and reference properties this is not essential information but it may be used by applications using the properties. For example it sometimes might have PTYP set to SPRE.
When the property returns a real value its PTYP attribute is important. It should be set to the type of physical quantity being returned. Its common values are:
NONE
-
a pure numeric, not a physical property
DIST
-
a Distance or Length property
BORE
-
a size of BORE property
DATA or ANY
-
any physical property so that any checking for consistency is met and no warning issued.
NONE
-
a pure numeric, not a physical property
DIST
-
a Distance or Length property
BORE
-
a size of BORE property
DATA or ANY
-
any physical property so that any checking for consistency is met and no warning issued.
In addition any standard hashcode for a supported physical quantity (dimension) can be used (MASS, ANGL, TEMP etc.) No checks are made for validity since the PTYP can be used by applications for their own needs. Any WORD not recognized is treated as NONE.
The PTYP can also be set to a generic dimension by setting the attribute to a compound unit value of such a dimension (a value has to be supplied for syntax purposes).
The DDPR and DDDF and VALIDValue expressions should all evaluate to a quantity whose dimension is the same or equivalent to the PTYPE
is suitable for a DDAT whose PTYP is DIST. If the expression evaluates to a pure numeric with no dimension then it is assumed to be in the current units of the PTYP dimension.
Warnings are issued if the PTYP does not match the evaluated physical quantity. This will occur when the PTYP is:
Warnings are suppressed if PTYP is:
The Property now is a physical quantity and this is persisted in any expression that the property is used in (including RULE type, Catalog, reverse Polish, and PML2 expressions).
It is transferred to any PML2 variable assigned to the property (!a = !!CE.LDPR.HEIG).
If the dimensions in the expression or function arguments do not match then further warnings will be generated:
NONE
-
a pure numeric, not a physical property
DIST
-
a Distance or Length property
BORE
-
a size of BORE property
DATA or ANY
-
any physical property so that any checking for consistency is met and no warning issued.
PTYP 1kg.degC-1.m2
DDPR ( XLEN of OWNER + 500mm)
a real value, or
a text string value, or
a reference value
a real value, or
a real value, or
a text string value, or
a text string value, or
a reference value
a reference value
NONE
not a valid dimension when it is taken to be NONE
a non matching valid dimension
NONE
NONE
not a valid dimension when it is taken to be NONE
not a valid dimension when it is taken to be NONE
a non matching valid dimension
a non matching valid dimension
REAL
DATA
ANY
REAL
REAL
DATA
DATA
ANY
ANY
Warning:
DIMENSION(UNIT) MISMATCH in arithmetic/arguments/assignment or format: ANGL expected but DIST supplied (element DDATA /DDSE2-DDAT2).

Warning
:


Assigning Local Names to Template Elements

When a design template is copied, confusion can arise in the identification of members of the template instance. If a template rule refers to an element by its hierarchic position (for example, BOX 1 OF TMPL 1 OF), rule execution errors can arise if the template instance is modified in any way which affects the ordering of the members list. Even if the element has an AVEVA E3D Design name under the Template World, this name will be lost when the template is copied because an element name cannot be used more than once in a Design database.
To avoid these problems, assign a local name (LNAME) to a template member. Each local name, and the reference of the corresponding element, is stored in an array attribute of the template. Local names are therefore set and queried at member element level, even though they are stored at template level. The local name survives a template copy operation.

local name


LNAME
Assign a local name to a template member, or unset an existing local name. A local name can have a maximum of 20 characters; a maximum of 500 local names can be stored on one template. The local name cannot be modified if either the element or its owning template is locked.
LNAME /ANTHONY
Sets local name for current element
LNAME UNSET
Unsets local name for current element
Q LNAMe
Gives local name for current element
Q LNLST
Lists all local names for elements under current template
Q ATT
Note:
Local names are stored in a compressed numeric format.
Q LNAMe
Gives local name for current element
Q LNLST
Lists all local names for elements under current template
Q ATT

Examples
LNAME /ANTHONY
Sets local name for current element
LNAME UNSET
Unsets local name for current element
Q LNAMe
Gives local name for current element
Q LNLST
Lists all local names for elements under current template
Q ATT
Note:
Local names are stored in a compressed numeric format.
>--- LNAMe ---*--- local_name ---.
              |                  |
              ‘--- UNSET --------+--->
Note:
Local names are stored in a compressed numeric format.

LNAME /ANTHONY
LNAME UNSET
>--- LNAMe ---*--- local_name ---.
              |                  |
              ‘--- UNSET --------+--->
Q LNAMe
Q LNLST
Q ATT
Note


LNID MLNID
Identify an element by its local name in a rule or dataset expression.
LNID /SID
Identifies element defined in current template
MLNID /JOE
Identifies element defined in member template (i.e. in template owned by current element)
(XLEN OF LNID /SID)
Uses dimension of locally named element in expression (XLEN OF MLNID /JOE)
Q LNID /SID
For element in current template
Q MLNID /JOE
For element in member template
Q LNID /SID
For element in current template
Q MLNID /JOE
For element in member template

Example
LNID /SID
Identifies element defined in current template
MLNID /JOE
Identifies element defined in member template (i.e. in template owned by current element)
(XLEN OF LNID /SID)
Uses dimension of locally named element in expression (XLEN OF MLNID /JOE)
Q LNID /SID
For element in current template
Q MLNID /JOE
For element in member template
>---+--- LNid ----.
    |             |
    ‘--- MLNid ---+--- local_name --->

LNID /SID
MLNID /JOE
(XLEN OF LNID /SID)
>---+--- LNid ----.
    |             |
    ‘--- MLNid ---+--- local_name --->
Q LNID /SID
Q MLNID /JOE


By default, the rules for the member elements of a design template are executed in descending hierarchic order. If the rule for one member element includes a reference to the result of a rule for another member, it is important that the latter rule is executed before the former, otherwise an incorrect result will be obtained.
The user can control the order in which the rules for a given template will be executed by assigning a rule sequence number to any element which has a local name. When the template rules are re-executed, the rules for such elements will be executed in ascending order of their sequence numbers: the rules for elements with sequence numbers unset (or zero) will then be executed in the default order. Each rule sequence number, and the reference of the corresponding element, is stored in an array attribute of the template. Rule sequence numbers are therefore set and queried at member element level, even though they are stored at template level.
RSEQNUMBER
Assign a rule sequence number to any design template member which has a local name. The rule sequence number must be a positive integer (zero is equivalent to unset). The same sequence number may be assigned to more than one element, but this is not recommended.
RSEQN 3
Sets rule sequence number for current element (which must be a member of a design template and must already have a local name)
RSEQN UNSET
Unsets rule sequence number for current element
Q RSEQN
Gives sequence number for current element
Q RSEQA
Lists sequence numbers for all elements under current template (in the order in which their local names were set)
Q RSEQFA
Lists local names for elements under current template, sorted by rule sequence number; that means, in order of rule execution priority
Q RSEQN
Gives sequence number for current element
Q RSEQA
Lists sequence numbers for all elements under current template (in the order in which their local names were set)
Q RSEQFA
Lists local names for elements under current template, sorted by rule sequence number; that means, in order of rule execution priority

Examples
RSEQN 3
Sets rule sequence number for current element (which must be a member of a design template and must already have a local name)
RSEQN UNSET
Unsets rule sequence number for current element
Q RSEQN
Gives sequence number for current element
Q RSEQA
Lists sequence numbers for all elements under current template (in the order in which their local names were set)
Q RSEQFA
Lists local names for elements under current template, sorted by rule sequence number; that means, in order of rule execution priority
>--- RSEQNumber ---+--- integer ---.
                   |               |
                   ‘--- UNSET -----+--->

rule sequence number
RSEQN 3
RSEQN UNSET
>--- RSEQNumber ---+--- integer ---.
                   |               |
                   ‘--- UNSET -----+--->
Q RSEQN
Q RSEQA
Q RSEQFA


Adding Design Points to Template Elements

The design datasets for a template, as discussed in Design Datasets, approximate to the Geomset data for a Catalog component. In a similar way, design templates can also own Design Pointsets (DPSE), which approximate to the Pointset data for a Catalog component. These let the user assign p-points to design template items, to be used as references for subsequent positioning and orientating operations.
A design pointset can store three types of p-point (note that these are not the same as those available in Catalog pointsets):
A Cartesian P-point is specified in terms of its X,Y,Z co-ordinates only, thus:
A Cylindrical P-point is specified as a position on the surface of a cylinder at a given position and with given dimensions, thus:
A Spherical P-point is specified as a position on the surface of a sphere at a given position and with given dimensions, thus:
A Cartesian P-point is specified in terms of its X,Y,Z co-ordinates only, thus:
A Cartesian P-point is specified in terms of its X,Y,Z co-ordinates only, thus:
A Cylindrical P-point is specified as a position on the surface of a cylinder at a given position and with given dimensions, thus:
A Cylindrical P-point is specified as a position on the surface of a cylinder at a given position and with given dimensions, thus:
A Spherical P-point is specified as a position on the surface of a sphere at a given position and with given dimensions, thus:
A Spherical P-point is specified as a position on the surface of a sphere at a given position and with given dimensions, thus:

Design Datasets
Design Datasets
Design Pointsets
Cartesian P-point
Cylindrical P-point
Spherical P-point


Using a Design Template Item in a Design

To create an instance of a ‘source’ design template in a design model, first create a template below the owning design element and then copy into this the details of the source template (which must be in a template world) from which it is to derive its data. The commands (at the design element which is to own the instance) are:
where template_identifier is the name of the source template. The effects are as follows:
To change an attribute explicitly, thereby causing it to differ from the design as specified in the source template, the user must first unset the ORRF references which point back to the source and unlock the members. To do so, use the command
where template_instance is the name of the copy TMPL in the design model hierarchy.
NEW TMPL
 COPY REXEcute template_identifier
UNTIE template_instance
All elements below the original design template are copied below the new TMPL.
All template rules are copied and re‑executed, thus setting the attributes of the new TMPL members to suit the design data.
The Origin Reference (ORRF) attributes for the new TMPL elements are set to point to their equivalents in the source template.
All elements below the new TMPL are locked to prevent unintentional changes to any of their attributes.
All elements below the original design template are copied below the new TMPL.
All elements below the original design template are copied below the new TMPL.
All template rules are copied and re‑executed, thus setting the attributes of the new TMPL members to suit the design data.
All template rules are copied and re‑executed, thus setting the attributes of the new TMPL members to suit the design data.
The Origin Reference (ORRF) attributes for the new TMPL elements are set to point to their equivalents in the source template.
The Origin Reference (ORRF) attributes for the new TMPL elements are set to point to their equivalents in the source template.
All elements below the new TMPL are locked to prevent unintentional changes to any of their attributes.
All elements below the new TMPL are locked to prevent unintentional changes to any of their attributes.

NEW TMPL
 COPY REXEcute
template_identifier
template_identifier
UNTIE
template_instance
template_instance


If the user lists the possible members of most types of design element, the user will see two elements called Portsets (PORS) and Linksets (LNKS). These are included in the database definitions to permit logical connections to be made to items derived from design templates by the AVEVA applications.


The Monitor Reference Manual has been written for users who need to customize their interface or write macros.
It is assumed that:
Users have a valid license and the software has been installed.
Users have completed the AVEVA Basic Training Course.
Users have a valid license and the software has been installed.
Users have a valid license and the software has been installed.
Users have completed the AVEVA Basic Training Course.
Users have completed the AVEVA Basic Training Course.

Monitor
.


This chapter describes what is happening at each stage of entering the application. It explains the way access to data and modules is controlled when the System Administrator sets up projects, users, teams and databases. Then it describes how you can use Monitor commands to query information about access rights to databases and modules, and about who is using the application.

Monitor


When you start up the application, you must first give the name of the project you will be working on using the PROJECT command. You can query the projects available. Then you specify a user name and password by giving the USERNAME command. You can query the users, and the MDBs, available in the Project before they are set.
When you have entered the username and password correctly, you will be in Monitor.
You will be able to use the facilities described in this manual, or start up another module.
Note:
When working in non-graphics mode, it is recommended that you enter the USERNAME command on its own, and you will then be prompted to enter the username and password, which will not be echoed on the screen. Do not follow the command immediately by the username and password, as this may be a security risk.

Note
:
Monitor


All data is stored in databases. To work on design data you must specify the name of a Multiple Database (MDB) before you enter another module. An MDB is a collection of databases with defined access rights. Specifying an MDB sets your access rights to the databases.
A MDB can contain up to 1000 DBs, and any number of the 1000 DBs can be described as current and accessed at one time. Databases which cannot be accessed are described as non-current or deferred. The status of a DB can be changed to Current or Defer at any time. Refer to Current and Non-current Databases for further information.
MONITOR checks that an MDB has been selected before it will allow you to enter another module (except ADMIN).
Refer to Current Working Units Initialization for further information.
Note:
When you select an MDB and enter a design module, UNITS settings are taken from the first current catalogue DB. Connection compatibility (COCO) tables in all the current catalogue DBs are available to the designer.

Current and Non-current Databases
Current Working Units Initialization
databases
Multiple Database
current
non-current
deferred
Current
Defer
Current and Non-current Databases
Note
:
first
all
Current Working Units Initialization


A Plant project can contain the following types of database:
System Databases
Model Databases
The SYSTEM database itself, which holds the access control data for the model data and modules.
The COMMS (Communications) database, which stores information about who is using which module and which model databases are available.
The MISC database which store inter-user messages, and inter-database macros.
In a Global project there will also be the Global database and a transaction database.
The SYSTEM database itself, which holds the access control data for the model data and modules.
The SYSTEM database itself, which holds the access control data for the model data and modules.
The COMMS (Communications) database, which stores information about who is using which module and which model databases are available.
The COMMS (Communications) database, which stores information about who is using which module and which model databases are available.
The MISC database which store inter-user messages, and inter-database macros.
The MISC database which store inter-user messages, and inter-database macros.
In a Global project there will also be the Global database and a transaction database.
In a Global project there will also be the Global database and a transaction database.
The Design database which contains all the design information for the project
The CATALOGUE database where the project catalogue and specifications are stored.
The PADD database which contains data about drawings produced by Draw.
The PROPERTIES database which can contain material properties, and can be referenced by the catalogue
The DICTIONARY database which holds the definitions of user-defined attributes (UDAs), as set up in Lexicon.
The ISOD database holds spool drawings generated by SPOOL.
The Design database which contains all the design information for the project
The Design database which contains all the design information for the project
The CATALOGUE database where the project catalogue and specifications are stored.
The CATALOGUE database where the project catalogue and specifications are stored.
The PADD database which contains data about drawings produced by Draw.
The PADD database which contains data about drawings produced by Draw.
The PROPERTIES database which can contain material properties, and can be referenced by the catalogue
The PROPERTIES database which can contain material properties, and can be referenced by the catalogue
The DICTIONARY database which holds the definitions of user-defined attributes (UDAs), as set up in Lexicon.
The DICTIONARY database which holds the definitions of user-defined attributes (UDAs), as set up in Lexicon.
The ISOD database holds spool drawings generated by SPOOL.
The ISOD database holds spool drawings generated by SPOOL.

Global
Global
Design
Draw
Lexicon


Users have one of the following types of access to a DB:
Read/Write
You can change the data held in the DB.
Read-only
You can interrogate the contents of the DB (for example, by using Isodraft to produce an isometric), but you cannot alter it.
None
You have no access to the DB.
Each database is set up with UPDATE, CONTROLLED or MULTIWRITE access rights, where:
UPDATE
The database can be accessed by many users with Read-only rights, but only one user with Read/Write right
CONTROLLED
Controlled by an external system.
MULTIWRITE
The database can be accessed by many users with Read/Write rights.
Read/Write
You can change the data held in the DB.
Read-only
You can interrogate the contents of the DB (for example, by using Isodraft to produce an isometric), but you cannot alter it.
None
You have no access to the DB.
Each database is set up with UPDATE, CONTROLLED or MULTIWRITE access rights, where:
UPDATE
The database can be accessed by many users with Read-only rights, but only one user with Read/Write right
CONTROLLED
Controlled by an external system.
MULTIWRITE
The database can be accessed by many users with Read/Write rights.
You can see the access rights to a database by using the LIST DB command.
Read/Write
You can change the data held in the DB.
Read-only
You can interrogate the contents of the DB (for example, by using Isodraft to produce an isometric), but you cannot alter it.
None
You have no access to the DB.
Each database is set up with UPDATE, CONTROLLED or MULTIWRITE access rights, where:
UPDATE
The database can be accessed by many users with Read-only rights, but only one user with Read/Write right
CONTROLLED
Controlled by an external system.
MULTIWRITE
The database can be accessed by many users with Read/Write rights.

Read/Write
Read-only
Isodraft
None
UPDATE
CONTROLLED
MULTIWRITE
LIST DB


Foreign databases are databases which have been included from a different project. This is often used for Catalogue databases, so that many users can have Read access to the same database without needing multiple copies. For example, in the Sample project supplied with the product, there are several databases shared with the Master project. Foreign databases are listed as such when databases are queried. Refer to QUERY.

QUERY
QUERY


A team is a user or a group of users who have read-write access to a database (and read access to several other databases). The database must be named as:
teamid/identifier
teamid
is the name of the team which is given full Read/Write access to the DB
identifier
is the name of the DB. This is a normal Plant name beginning with a slash (/).
teamid
is the name of the team which is given full Read/Write access to the DB
identifier
is the name of the DB. This is a normal Plant name beginning with a slash (/).
For example, the PIPING team would have read-write access to design databases containing piping design, the STRUCTURES team would have read-write access to databases containing steelwork design, but they would both have read-only access to a catalogue database. So, the MDB for the PIPING team could contain the following databases (and normally several others):
PIPING/PIPING-A
A Design database PIPING-A, to which the PIPING team will have read/write access.
MASTER/CATALOGUE-1
A Catalogue database CATALOGUE-1, to which the PIPING team will have read-only access.
PIPING/PIPING-A
A Design database PIPING-A, to which the PIPING team will have read/write access.
MASTER/CATALOGUE-1
A Catalogue database CATALOGUE-1, to which the PIPING team will have read-only access.

teamid
is the name of the team which is given full Read/Write access to the DB
identifier
is the name of the DB. This is a normal Plant name beginning with a slash (/).
PIPING/PIPING-A
A Design database PIPING-A, to which the PIPING team will have read/write access.
MASTER/CATALOGUE-1
A Catalogue database CATALOGUE-1, to which the PIPING team will have read-only access.

team
teamid/identifier
teamid
identifier


Each user has a level of access assigned by the System Administrator:
Free users have read-write access to all databases.
General users have read-write access to databases owned by their team in the current MDB, and read-only access to other copies of databases in the current MDB.
Free users have read-write access to all databases.
Free users have read-write access to all databases.
General users have read-write access to databases owned by their team in the current MDB, and read-only access to other copies of databases in the current MDB.
General users have read-write access to databases owned by their team in the current MDB, and read-only access to other copies of databases in the current MDB.

Free
General


Any module can be classified as Free, or Restricted. Whether a user has access to a module will depend on the user’s access rights and the access classification of the module, as follows:
In the system configuration as supplied, only Admin and Lexicon are Restricted. All the other modules are Free.
Only a Free user may use a Restricted module
A General user may use Free modules
Only a Free user may use a Restricted module
Only a Free user may use a Restricted module
A General user may use Free modules
A General user may use Free modules

Admin
Lexicon


This chapter is an overview of Monitor commands. They are mainly used to select databases and modules, to query information about the system status, users and databases, and to communicate with other users.
Refer to Command Summary for further information.

Command Summary
Monitor
Command Summary


You can change your password from that allocated to you by the System Administrator. The command PASS is followed by a slash and then the new password, consisting of up to fifteen characters, excluding I’@$/*".

PASS


The STATUS command outputs information about your current status and the databases to which you have access. Refer to STATUS for a detailed description of the status command.

STATUS
STATUS
STATUS


The SYSTAT (System Status) command outputs information about the current active status of the project. It lists all users who are accessing the project at that time, the modules and databases which they are using, and whether they are examining (Read-only status) or modifying (Read/Write status) the database. It also gives the unique identifier of each user. Refer to SYSTAT for a detailed description of the SYSTAT command.

SYSTAT
SYSTAT
active
SYSTAT


The SET command sets the specified team as the current one. Once a team has been set, DBs owned by that team can be referred to by using the name part only. For example, after the command
You could give the command
Instead of the command

SET
SET TEAM SAMPLE
Q DB /DESI
Q DB SAMPLE/DESI


The LIST and QUERY commands can be used to display information about Users, Teams, MDBs and Databases. LIST outputs general information, and QUERY outputs information about a named item. Note that there are many other options in the QUERY command available in other modules; the ones described here are those available in Monitor.
The LIST command outputs information about:

LIST
QUERY
LIST
QUERY
QUERY
Monitor
LIST
Users
MDBs
DBs
Teams
Copies of databases
Modules


An example of typical output from the command LIST USERS is shown below. It lists all the users in the project, with their access level (Free or General), and the teams they belong to:
List of USERS for project SAM
 ===============================
 SYSTEM   (Free)
 Teams : MASTER   SAMPLE   DEMO   HANGERS  HVAC PIPE
         DRAFTADMIN   ISOADMIN HSADMIN  ADMIN
          SAMPLE   (General)
          Teams : SAMPLE
          DEMO     (General)
          Teams : DEMO
          HANGERS  (General)
          Teams : HANGERS
               (General)
          Teams : HVAC
          PIPE     (General)
          Teams : PIPE

LIST USERS
List of USERS for project SAM
 ===============================
 SYSTEM   (Free)
 Teams : MASTER   SAMPLE   DEMO   HANGERS  HVAC PIPE
         DRAFTADMIN   ISOADMIN HSADMIN  ADMIN
          SAMPLE   (General)
          Teams : SAMPLE
          DEMO     (General)
          Teams : DEMO
          HANGERS  (General)
          Teams : HANGERS
               (General)
          Teams : HVAC
          PIPE     (General)
          Teams : PIPE


An example of typical output from the command LIST TEAMS is shown below. It lists all the teams in the project, with the users who are members of the teams and the DBs associated with them.
List of TEAMS for project SAM
 ===============================
 MASTER
 USERS: SYSTEM
 DBS: /PIPECATA  /PIPEOLD /STLCATA /HVACCATA  /SUPPCATA
      /PADD    /DICT    /PROP

SAMPLE
USERS: SYSTEM   SAMPLE
DBS: /DESI    /PADD    /COMP

DEMO
USERS: SYSTEM   DEMO
DBS: /DESI    /PADD    /COMP

...
...

ADMIN
USERS: SYSTEM
DBS: /PADD

LIST TEAMS


The command LIST MDB lists the MDBs in the project. For each MDB it lists the databases it contains, their types (DESI, CATA, ), access level (for example, UPDATE), and the current and deferred databases. For example:
List of MDBS for project SAM
 ==============================
 MDB: /SAMPLE
 Current DBS:
   1  SAMPLE/DESI              DESI Update
   2  SAMPLE/PADD              PADD Update
   3  ADMIN/PADD               PADD Update
   4  SAMPLE/COMP              COMP Update
   5  MASTER/PIPECATA          CATA Update Foreign
   6  MASTER/PIPEOLD           CATA Update Foreign
   7  MASTER/STLCATA           CATA Update Foreign
   8  MASTER/HVACCATA          CATA Update Foreign
   9  MASTER/SUPPCATA          CATA Update Foreign
  10  MASTER/PADD              PADD Update Foreign
  11  MASTER/DICT              DICT Update Foreign
  12  MASTER/PROP              PROP Update Foreign
 Deferred DBS:
 **NONE**
MDB: /DEMO
 Current DBS:
   1  DEMO/DESI                 DESI Update
   2  DEMO/PADD                 PADD Update
   ...

LIST MDB


The command LIST DB lists all the databases in the project, their types (DESI, CATA, ) and the MDBs which contain them. For example:
List of DBS for project SAM
 =============================
 MASTER/PIPECATA    CATA FOREIGN   Number 8101 Update
   Size 7623 pages
 MDBS: /SAMPLE  /DEMO    /HANGERS /HVAC    /PIPE

MASTER/PIPEOLD    CATA FOREIGN   Number 8105 Update
   Size 4861 pages
 MDBS: /SAMPLE  /DEMO    /HANGERS /HVAC    /PIPE

ADMIN/PADD        PADD   Number 8013 Update
   Size  51 pages
 MDBS: /SAMPLE  /DEMO
 ...
 ...


The command LIST COPIES displays the names of all DBs which have been copied from a different project and the names under which the copies are filed. For example:
List of sets of copied DBS for project ABC
 ============================================
 Database PIPING-A/DESI has copies:
   PIPING-X/DESI

LIST COPIES


The LIST MODULES command lists information about modules in the current project. It may be useful if you are having difficulty accessing a module for some reason, but you will need access to Admin to make any changes.
List of modules for project SAM
 =================================

Module 0  MONITOR
          Security Free
          Imacro /%PMLUI%/MON/ADMIN/START
          Open  Attlib /%AVEVA_DESIGN_EXE%/attlib.dat
          Open  Message /%AVEVA_DESIGN_EXE%/message.dat
           Resume /%AVEVA_DESIGN_EXE%/mon

Module 1  ADMIN
          Security Restricted
          Buffer 2560000
           Resume /%AVEVA_DESIGN_EXE%/adm

...

LIST MODULES
Admin


The QUERY command outputs information about named administration elements.
Note that there are many other elements and attributes of elements that can be queried in other modules. This section lists those available in Monitor.
Some examples of output from querying commands are given below. For a complete specification of the options, see the command syntax.
Command
Output
Q USER
User: SAMPLE
Q USER SAMPLE
SAMPLE   (General)
Teams : SAMPLE

Q USER SYSTEM ACCESS
(Free)
Q USER SYSTEM DESCRIPTION
system administrator
Command
Output
Current DBS:1 SAMPLE/DESI  DESI Update
            2 SAMPLE/PADD  PADD Update
               . . .
          11 MASTER/DICT DICT Update Foreign
          12 MASTER/PROP PROP Update Foreign
          Deferred DBS:
          **NONE**
LIST
Command
Output
Q USER
User: SAMPLE
Q USER SAMPLE
SAMPLE   (General)
Teams : SAMPLE

Q USER SYSTEM ACCESS
(Free)
Q USER SYSTEM DESCRIPTION
system administrator
Q ACTIVE
Number of Active Users is 1
Q TEAM SAMPLE
SAMPLE
USERS: SYSTEM   SAMPLE
DBS: /DESI    /PADD    /COMP
Q TEAM SAMPLE DESCRIPTION
Team for Sample Project
q set team
** SAMPLE **
Q MDB /SAMPLE
MDB: /SAMPLE
Current DBS:1 SAMPLE/DESI  DESI Update
            2 SAMPLE/PADD  PADD Update
               . . .
          11 MASTER/DICT DICT Update Foreign
          12 MASTER/PROP PROP Update Foreign
          Deferred DBS:
          **NONE**
Q MDB /SAMPLE
MDB for Sample Project
Q DB SAMPLE/DESI
SAMPLE/DESI DESI Number 8010 Update
Size 664 pages

MDBS: /SAMPLE
Q DB MASTER/PIPEOLD TYPE
CATA
Q DB MASTER/PIPECATA FILE
Filename /%MAS000%/mas005
Q DB MASTER/PIPECATA NUMBER
Number 8101
Q DB MASTER/PIPECATA SIZE
Size 623 pages
Q DB MASTER/PIPECATA FOREIGN
FOREIGN
Q DB SAMPLE/DESI FOREIGN
Local
Q DB SAMPLE/DESI ACCESS
Update
Q COPIES SAMPLE/DESI
Database SAMPLE/DESI has copies: ABC/DESI
Q MACRO 1
/%SAMMAC%/sam001.mac TEST/DESI SAMPLE/DESI
Q MACRO 1 FROM
TEST/DESI
Q PROJ
Number (01223) 556666
Name Sample Project
Description
Sample Released
Project
Message AVEVA Project - Example Only

>--- Query ---+--- USer ---+-------------------------------.
              |            |                               |
              |            ‘--- userid --+-- ACCess -------|
              |                          |                 |
              |                          |-- DESCription --|
              |                          |                 |
              |                          ‘-- PASS ---------|
              |                                            |
              |--- ACTIVE ---------------------------------|
              |                                            |
              |--- TEam teamid ----------+-----------------|
              |                          |                 |
              |                          ‘-- DESCription --|
              |                                            |
              |--- DB dbname --+---------------------------|
              |                |                           |
              |                |-- DESCription ------------|
              |                |                           |
              |                |-- TYpe -------------------|
              |                |                           |
              |                |-- FIle -------------------|
              |                |                           |
              |                |-- NUmber -----------------|
              |                |                           |
              |                |-- SIze -------------------|
              |                |                           |
              |                |-- FOREign ----------------|
              |                |                           |
              |                ‘-- ACCess -----------------|
              |                                            |
              |--- COpies dbname --------------------------|
              |                                            |
              |--- MDB mdbname --+-------------------------|
              |                  |                         |
              |                  ‘-- DESCription ----------|
              |                                            |
              |--- MACRO integer --+-----------------------|
              |                    |                       |
              |                    |-- FILEname -----------|
              |                    |                       |
              |                    |-- FROMdb -------------|
              |                    |                       |
              |                    ‘-- TOdb ---------------|
              |                                            |
              |--- PASSWORDLOCK ---------------------------|
Note:
Description must have been set.
Note:
This information will only be output if you are a Free user.
Note:
A description must have been set.
Note:
A description must have been set.

QUERY
Monitor
Command
Output
Note
:
Note
:
Note
:
Note
:
>--- Query ---+--- USer ---+-------------------------------.
              |            |                               |
              |            ‘--- userid --+-- ACCess -------|
              |                          |                 |
              |                          |-- DESCription --|
              |                          |                 |
              |                          ‘-- PASS ---------|
              |                                            |
              |--- ACTIVE ---------------------------------|
              |                                            |
              |--- TEam teamid ----------+-----------------|
              |                          |                 |
              |                          ‘-- DESCription --|
              |                                            |
              |--- DB dbname --+---------------------------|
              |                |                           |
              |                |-- DESCription ------------|
              |                |                           |
              |                |-- TYpe -------------------|
              |                |                           |
              |                |-- FIle -------------------|
              |                |                           |
              |                |-- NUmber -----------------|
              |                |                           |
              |                |-- SIze -------------------|
              |                |                           |
              |                |-- FOREign ----------------|
              |                |                           |
              |                ‘-- ACCess -----------------|
              |                                            |
              |--- COpies dbname --------------------------|
              |                                            |
              |--- MDB mdbname --+-------------------------|
              |                  |                         |
              |                  ‘-- DESCription ----------|
              |                                            |
              |--- MACRO integer --+-----------------------|
              |                    |                       |
              |                    |-- FILEname -----------|
              |                    |                       |
              |                    |-- FROMdb -------------|
              |                    |                       |
              |                    ‘-- TOdb ---------------|
              |                                            |
              |--- PASSWORDLOCK ---------------------------|
              |                                            |
              |--- SET TEam -------------------------------|
              |                                            |
              ‘--- PROject ---+--- NAMe -------------------|
                              |                            |
                              |--- NUMber -----------------|
                              |                            |
                              |--- DEScription ------------|
                              |                            |
                              ‘--- MESsage ----------------+-->


The PROTECT command allows you to alter your access rights to specified DBs for the current session. You can only reduce your access rights from the set state, never increase them. This command can be used on the current MDB. Refer to PROTECT for a detailed description of the PROTECT command.

PROTECT
PROTECT
PROTECT


A MDB can contain up to 1000 DBs, and any number of the 1000 DBs can be described as current and accessed at one time. Databases which cannot be accessed are described as non-current or deferred.
EXCHANGE replaces a current DB by a non-current DB. The DB names do not need to be listed in a particular order, since the MDB knows which are current and which are non-current, but they must be paired correctly if more than two names are listed.
CURRENT includes the specified DB at a given position in the Current list.
DEFER removes the specified DB from the Current list and makes it non-current.
For example, assume that an MDB contains the following DBs as shown by a LIST command:
The command
would result in the new configuration
The effect of the command
after the EXCHANGE command is to insert the named DBs at positions 1 and 4 respectively in the Current list, resulting in
Note that the position specified for each DB to be added to the Current list applies after the previous insertions have been made.
/DESIGN
Current DBS:   PIPING/PIPING-A    PIPING/PIPINGC
MASTER/CATA-D
Deferred DBS:   PIPING/PIPING-B    MASTER/PIPING-
EXCHANGE PIPING/PIPING-A PIPING/PIPING-B MASTER/PIPING-E MASTER/CATA-D
/DESIGN
Current DBS:  PIPING/PIPING-B   PIPING/PIPING-C
MASTER/PIPING-E
Deferred DBS: PIPING/PIPING-A   MASTER/CATA-D
CURRENT PIPING/PIPING-A 1  MASTER/CATA-D 4
/DESIGN
Current DBS: PIPING/PIPING-A PIPING/PIPING-B PIPING/PIPING-C          MASTER/CATA-D
MASTER/PIPING-E
Deferred DBS:**NONE**
Note:
The current DBs PIPING/PIPING-A and MASTER/CATA-D are replaced by the DBs PIPING/PIPING-B and MASTER/PIPING-E respectively, even though they are listed out of sequence in the EXCHANGE command.

current
non-current
deferred.
EXCHANGE
CURRENT
DEFER
LIST
/DESIGN
Current DBS:   PIPING/PIPING-A    PIPING/PIPINGC
MASTER/CATA-D
Deferred DBS:   PIPING/PIPING-B    MASTER/PIPING-
EXCHANGE PIPING/PIPING-A PIPING/PIPING-B MASTER/PIPING-E MASTER/CATA-D
/DESIGN
Current DBS:  PIPING/PIPING-B   PIPING/PIPING-C
MASTER/PIPING-E
Deferred DBS: PIPING/PIPING-A   MASTER/CATA-D
Note
:
EXCHANGE
CURRENT PIPING/PIPING-A 1  MASTER/CATA-D 4
EXCHANGE
/DESIGN
Current DBS: PIPING/PIPING-A PIPING/PIPING-B PIPING/PIPING-C          MASTER/CATA-D
MASTER/PIPING-E
Deferred DBS:**NONE**
after


You can send messages to other users of the project using the MESSAGE command.
Messages sent using the MESSAGE command will only be displayed to users already in the project when the command is given, and then only when they next change modules. You can send messages to:
The text of the message must be enclosed in quotes. For example:
MESS TEAM PIPING  ’LATEST PIPE ROUTING HAS BEEN APPROVED’
An individual user, specified by name or identifier
All members of a specified team
All active project users
All users logged into a given host
All users with a given line number
An individual user, specified by name or identifier
An individual user, specified by name or identifier
All members of a specified team
All members of a specified team
All active project users
All active project users
All users logged into a given host
All users logged into a given host
All users with a given line number
All users with a given line number
Note:
The message must be enclosed in quotes.

MESSAGE
MESSAGE
MESS TEAM PIPING  ’LATEST PIPE ROUTING HAS BEEN APPROVED’
Note
:


The data output by the commands described in this chapter can be sent to the screen or to a file. By default, the data is sent to the screen, but it can be directed to a file using the ALPHA FILE or FILE command. These commands also specify the number of characters in a line and the number of lines on a page, and whether the file should be overwritten if new data is sent to it.
If you have specified that output should be sent to a file using the ALPHA FILE command, you can return to output being sent to the screen by giving the ALPHA FILE END command. If you have specified that output should be sent to a file using the FILE command, you must use the TERMINAL command to send output to the screen. ALPHA FILE is recommended for normal use.
The default is TERMINAL WITH 80 CHARACTERS.

ALPHA FILE
FILE
ALPHA FILE
ALPHA FILE END
FILE
TERMINAL
ALPHA FILE
TERMINAL WITH 80 CHARACTERS


You will normally have a default output device set. The default output devices for both text and graphics are shown in a message which is displayed when the application is started up. You can use the DEVICE command to change your output device, for example, if you do not want any graphics to be displayed.

DEVICE


You can enter any module which is installed on your system and to which you have access by typing its name.
You can return to Monitor from any other module by giving the command
Monitor

Monitor
Monitor


Deleting Inter-database Connection Macros

The DELETE command is used to delete inter-DB connection macros, which are created in a Design module when connections are made across databases.

DELETE


The FINISH command terminates the current session and returns you to the operating system.

FINISH


To run jobs in batch mode, the application must be started up in batch mode. To set up a batch job, you must create a file containing all the commands which you would normally enter at the keyboard, and possibly add other commands required by the computer’s batch system. Then run the file using the normal command in your operating system. Refer to BATCH.

BATCH
BATCH


This section lists the Monitor commands, with a brief description of each.
BATCH
Specifies commands for running in batch mode.
CURRENT
Makes a database current.
DEFER
Makes a database non-current (deferred).
DELETE
Deletes inter-DB connection macros.
DEVICE
Specifies a device type.
EXCHANGE
Replaces a current database by a deferred one.
FINISH
Exits the application.
LIST
Lists information about the project.
MESSAGE
Sends a message to other users.
PASSWORD
Changes your password.
PROJECT
Specifies the current project.
PROTECT
Changes your access rights to databases.
QUERY
Outputs information about named administration elements (Users, Teams, etc).
RUN
Runs modules which are not available through the normal module-changing commands.
SYSTAT
Outputs status information about the current project.
USERNAME
Specifies a username and password.
BATCH
Specifies commands for running in batch mode.
CURRENT
Makes a database current.
DEFER
Makes a database non-current (deferred).
DELETE
Deletes inter-DB connection macros.
DEVICE
Specifies a device type.
EXCHANGE
Replaces a current database by a deferred one.
FINISH
Exits the application.
LIST
Lists information about the project.
MESSAGE
Sends a message to other users.
PASSWORD
Changes your password.
PROJECT
Specifies the current project.
PROTECT
Changes your access rights to databases.
QUERY
Outputs information about named administration elements (Users, Teams, etc).
RUN
Runs modules which are not available through the normal module-changing commands.
SYSTAT
Outputs status information about the current project.
USERNAME
Specifies a username and password.

BATCH
Specifies commands for running in batch mode.
CURRENT
Makes a database current.
DEFER
Makes a database non-current (deferred).
DELETE
Deletes inter-DB connection macros.
DEVICE
Specifies a device type.
EXCHANGE
Replaces a current database by a deferred one.
FINISH
Exits the application.
LIST
Lists information about the project.
MESSAGE
Sends a message to other users.
PASSWORD
Changes your password.
PROJECT
Specifies the current project.
PROTECT
Changes your access rights to databases.
QUERY
Outputs information about named administration elements (Users, Teams, etc).
RUN
Runs modules which are not available through the normal module-changing commands.
SYSTAT
Outputs status information about the current project.
USERNAME
Specifies a username and password.

Monitor


The commands described in this chapter are presented in the form of syntax graphs.
Commands are shown in a combination of uppercase and lowercase letters, where the capital letters indicate the minimum abbreviation.
For example, the command
can be input in any of the following forms:
means that to set a password to secret, you enter:
Command arguments are just descriptions of what you need to enter, and the description shown should be replaced by the text or value required. The following table shows some examples:
name
An element name
PIPE-A63
refno
A reference number
=23/1403
integer
A positive integer
3
value
A positive or negative number
3.142
word
A sequence of up to 4 letters
FLOW
text
An alphanumeric string
‘Enclose in quotes’
filename
The pathname of a file
/c:\\testing
Name
Definition
Example
name
An element name
PIPE-A63
refno
A reference number
=23/1403
integer
A positive integer
3
value
A positive or negative number
3.142
word
A sequence of up to 4 letters
FLOW
text
An alphanumeric string
‘Enclose in quotes’
filename
The pathname of a file
/c:\\testing
Note:
When a full pathname is given, the first slash is needed because all names in the application must start with a slash.
Query
Q
QU
QUE
QUER
QUERY
PASSWORD password
PASSWORD /SECRET
 >----+--- ABC -----.
      |             |
      |--- PQR -----|
      |             |
      ‘-------------+--->
              .-----<-------.
             /              |
        >---*--- option1 ---|
            |               |
            |--- option2 ---|
            |               |
            ‘--- option3 ---+--->
             .----<------.
            /            |
       >---*--- name ----+--->
Commands shown in all uppercase letters cannot be abbreviated.
Command arguments are shown in lowercase italic letters. For example:
PASSWORD password
Commands shown in all uppercase letters cannot be abbreviated.
Commands shown in all uppercase letters cannot be abbreviated.
Command arguments are shown in lowercase italic letters. For example:
PASSWORD password
Command arguments are shown in lowercase italic letters. For example:
Syntax graphs are read from top left to bottom right. The start point is shown by >, and you can follow any path through the graph until the exit point, shown by >, is reached.
Points marked with a plus sign (+) are option junctions which allow you to input any one of the commands to the right of the junction. For example:
 >----+--- ABC -----.
      |             |
      |--- PQR -----|
      |             |
      ‘-------------+--->
means you can type in ABC or PQR or just press Enter to get the default option.
Points marked with an asterisk (*) are loop back junctions. Command options following these may be repeated as required.
For example:
              .-----<-------.
             /              |
        >---*--- option1 ---|
            |               |
            |--- option2 ---|
            |               |
            ‘--- option3 ---+--->
means that you can enter any combination of option1 and/or option2 and/or option3, where the options can be commands, other syntax diagrams, or command arguments.
The simplified format:
             .----<------.
            /            |
       >---*--- name ----+--->
means that you may type in a list of names, separated by at least one space.
Syntax graphs are read from top left to bottom right. The start point is shown by >, and you can follow any path through the graph until the exit point, shown by >, is reached.
Syntax graphs are read from top left to bottom right. The start point is shown by >, and you can follow any path through the graph until the exit point, shown by >, is reached.
Points marked with a plus sign (+) are option junctions which allow you to input any one of the commands to the right of the junction. For example:
 >----+--- ABC -----.
      |             |
      |--- PQR -----|
      |             |
      ‘-------------+--->
means you can type in ABC or PQR or just press Enter to get the default option.
Points marked with a plus sign (+) are option junctions which allow you to input any one of the commands to the right of the junction. For example:
Points marked with an asterisk (*) are loop back junctions. Command options following these may be repeated as required.
For example:
              .-----<-------.
             /              |
        >---*--- option1 ---|
            |               |
            |--- option2 ---|
            |               |
            ‘--- option3 ---+--->
means that you can enter any combination of option1 and/or option2 and/or option3, where the options can be commands, other syntax diagrams, or command arguments.
Points marked with an asterisk (*) are loop back junctions. Command options following these may be repeated as required.
The simplified format:
             .----<------.
            /            |
       >---*--- name ----+--->
means that you may type in a list of names, separated by at least one space.
The simplified format:
Note:
This convention does not mean that the second part of the command must be typed in lowercase letters; commands may be entered in any combination of uppercase and lowercase letters.
Note:
When a full pathname is given, the first slash is needed because all names in the application must start with a slash.

syntax graphs
Note
:
Query
Q
QU
QUE
QUER
QUERY
PASSWORD password
PASSWORD /SECRET
Name
Definition
Example
name
refno
integer
value
word
text
filename
Note
:
option junctions
 >----+--- ABC -----.
      |             |
      |--- PQR -----|
      |             |
      ‘-------------+--->
or
or
loop back junctions
              .-----<-------.
             /              |
        >---*--- option1 ---|
            |               |
            |--- option2 ---|
            |               |
            ‘--- option3 ---+--->
and/or
and/or
             .----<------.
            /            |
       >---*--- name ----+--->


The BATCH command enables you to specify how batch jobs will be processed.
To run jobs in batch mode, the application must be started up in batch mode.
When you enter the application interactively, you are allowed three attempts at giving your correct username and password. When the application is started up in batch mode, only one attempt is permitted. If either the username or password are incorrect, control will pass back to the operating system and that job will be terminated.
The BATCH COPY command allows you to take copies of DBs with Read/Write access, provided you have Read/Write access to the database. The batch job accesses these copies and so allows interactive users to carry on using the normal copies. Write access to copies of DBs is needed to allow functions such as automatic group creation to be carried out.
By default, if a COPY command is not given, copies are made of all Design DBs.
If copies are not taken of DBs, then the originals are accessed in Read-only mode, irrespective of the normal access rights (which may be Read/Write).
You can specify that you want all the databases of a given type to be copied, for example, all the PADD databases, or you can specify named databases, all databases or none. You can specify a group of databases of a given type, and then use the NOCOPY option to stop copies of named databases or specified types of database being made.
The copies taken by the BATCH COPY command are temporary. They disappear when the batch job exits from the application (whether successfully completed or not) or when the batch file selects a new MDB. If permanent copies are required, they must be made by the System Administrator using Admin.
Access to databases through Admin and RECONFIGURER can only be made in Read-only mode, even if the databases have been copied with Read/Write access. Any attempt to alter the project structure for batch jobs, even temporarily, will result in the message:
BATCH COPY DESI DRWG
Copies will be made of all Design and Drawing DBs in the selected MDB.
BATCH COPY PIPING/DES74A CIVIL/DES13B
Copies will be made of the two named DBs.
BATCH COPY ALL
Copies will be made of all DBs in the MDB.
BATCH COPY NONE
No copies will be made of any DB.
BATCH NOCOPY PIPING/DES74A
The database PIPING/DES74A will not be copied.
BATCH COPY DESI DRWG
Copies will be made of all Design and Drawing DBs in the selected MDB.
BATCH COPY PIPING/DES74A CIVIL/DES13B
Copies will be made of the two named DBs.
BATCH COPY ALL
Copies will be made of all DBs in the MDB.
BATCH COPY NONE
No copies will be made of any DB.
BATCH NOCOPY PIPING/DES74A
The database PIPING/DES74A will not be copied.
COPY commands are additive; that is, each new COPY command is added to the result of all previous COPY commands. For example, consider an MDB containing the following DBs:
If the batch file contains the commands:
The following DBs would be marked as requiring copies:
For a batch job to start, the application must be able to access all the databases it needs, either to make copies of them or to access them directly.
When a batch run starts, and the first module change command occurs, Monitor will make copies of any DBs marked for copying.
As the batch file could alter the status of databases in an MDB by using the DEFER, CURRENT or EXCHANGE commands, or could change to a different MDB, copies are not taken until immediately after the command to change to another module. If a new MDB is selected, or the same MDB is reselected and copies of DBs exist from the last time the MDB was accessed, then all existing copies are deleted and fresh copies are taken. It is important for batch users to assess the effect of copying DBs on disk space.
When you use the batch facilities, you must put your username and password into a file. This is a potential breach of the security system provided by the application, from two points of view.
There is some risk of corruption of the COMMS DB (the only DB written to in Read-only batch operation) if a batch-mode job is interrupted before completion.
To reduce the risk of serious corruption of the COMMS DB, you should take the following precautions:
where dbtype is one of the following:
DESI CATA PROP PADD DICT ISOD
BATCH COPY DESI DRWG
Copies will be made of all Design and Drawing DBs in the selected MDB.
BATCH COPY PIPING/DES74A CIVIL/DES13B
Copies will be made of the two named DBs.
BATCH COPY ALL
Copies will be made of all DBs in the MDB.
BATCH COPY NONE
No copies will be made of any DB.
BATCH NOCOPY PIPING/DES74A
The database PIPING/DES74A will not be copied.
MASTER/CATA                 CATA
PIPING/DES74A               DESI
PIPING/DES75A               DESI
PIPING/DES37C               DESI
CIVIL/DES74A                DESI
CIVIL/DES75A                DESI
CIVIL/DES37C                DESI
MATS/PROP2                  PROP

BATCH  COPY  NONE
BATCH  COPY  PIPING/DES75A  PIPING/DES37C
BATCH  COPY  DRWG

PIPING/DES75A              DESI
PIPING/DES37C              DESI

                            .----------<---------.
                           /                     |
>-- BAtch ---+--- COpy ---*--- ALL --------------|
             |            |                      |
             |            |--- NONE -------------|
             |            |                      |
             |            |--- dbtype -----------|
             |            |                      |
             |            ‘--- dbname -----------|
             |                                   |
             |                .-----<------.     |
             |               /             |     |
             ‘--- NOCOpy ---*--- dbtype ---|     |
                            |              |     |
                            ‘--- dbname ---+-----+--->
If the project name, username or password are incorrectly specified while trying to gain access in batch mode, the application will immediately abort.
If any other errors occur, the batch job will immediately be aborted, unless PML error handling has been used. Refer to Variables, Objects, Functions and Methods for information about PML.
If the project name, username or password are incorrectly specified while trying to gain access in batch mode, the application will immediately abort.
If the project name, username or password are incorrectly specified while trying to gain access in batch mode, the application will immediately abort.
If any other errors occur, the batch job will immediately be aborted, unless PML error handling has been used. Refer to Variables, Objects, Functions and Methods for information about PML.
If any other errors occur, the batch job will immediately be aborted, unless PML error handling has been used. Refer to Variables, Objects, Functions and Methods for information about PML.
Unless the batch file is protected from access by other users, they will be able to read it and find out the username and password contained in it. You should make sure that operating system security is used to protect batch files.
Many batch systems operate by taking a copy of the file submitted for batch execution. If this copy is held somewhere accessible to normal (non-system) users, then even if the user submitting the job has protected his own files, his username and password could still be read from the copy. Project Coordinators should consult their Computer Systems department to make sure that this is not the case on their particular computer.
Unless the batch file is protected from access by other users, they will be able to read it and find out the username and password contained in it. You should make sure that operating system security is used to protect batch files.
Unless the batch file is protected from access by other users, they will be able to read it and find out the username and password contained in it. You should make sure that operating system security is used to protect batch files.
Many batch systems operate by taking a copy of the file submitted for batch execution. If this copy is held somewhere accessible to normal (non-system) users, then even if the user submitting the job has protected his own files, his username and password could still be read from the copy. Project Coordinators should consult their Computer Systems department to make sure that this is not the case on their particular computer.
Many batch systems operate by taking a copy of the file submitted for batch execution. If this copy is held somewhere accessible to normal (non-system) users, then even if the user submitting the job has protected his own files, his username and password could still be read from the copy. Project Coordinators should consult their Computer Systems department to make sure that this is not the case on their particular computer.
Do not send remote instructions to abort a batch job. The job interruption could occur while the COMMS DB is being updated.
Do not use batch queues where CPU or elapsed time restrictions are in force.
Do not execute batch jobs if there is a risk of running out of disk space.
Do not send remote instructions to abort a batch job. The job interruption could occur while the COMMS DB is being updated.
Do not send remote instructions to abort a batch job. The job interruption could occur while the COMMS DB is being updated.
Do not use batch queues where CPU or elapsed time restrictions are in force.
Do not use batch queues where CPU or elapsed time restrictions are in force.
Do not execute batch jobs if there is a risk of running out of disk space.
Do not execute batch jobs if there is a risk of running out of disk space.

Variables, Objects, Functions and Methods
BATCH
BATCH COPY
COPY
NOCOPY
BATCH COPY
Admin
Admin
COPY
COPY
COPY
Monitor
Monitor
DEFER, CURRENT
EXCHANGE
Variables, Objects, Functions and Methods
Do not
Do not
Do not
                            .----------<---------.
                           /                     |
>-- BAtch ---+--- COpy ---*--- ALL --------------|
             |            |                      |
             |            |--- NONE -------------|
             |            |                      |
             |            |--- dbtype -----------|
             |            |                      |
             |            ‘--- dbname -----------|
             |                                   |
             |                .-----<------.     |
             |               /             |     |
             ‘--- NOCOpy ---*--- dbtype ---|     |
                            |              |     |
                            ‘--- dbname ---+-----+--->
dbtype


The CURRENT command makes a database current.
A MDB can contain up to 1000 DBs, and any number of the 1000 DBs can be described as current and accessed at one time. Databases which cannot be accessed are described as non-current or deferred. CURRENT makes the specified DB current and includes it at position n in the current list of the MDB (where n is in the range 1 to 1000 inclusive).
Makes the databases PIPING/PIPING-A and PIPING/PIPING-C current
DEFER EXCHANGE
CURRENT PIPING/PIPING-A PIPING/PIPING-C
    Makes the databases PIPING/PIPING-A and PIPING/PIPING-C current
CURRENT PIPING/PIPING-A PIPING/PIPING-C
    Makes the databases PIPING/PIPING-A and PIPING/PIPING-C current
CURRENT PIPING/PIPING-A PIPING/PIPING-C
                  .--------------.
                 /               |
>--- CUrrent ---*--- dbname n ---+--->

CURRENT
current
non-current
deferred
CURRENT
n
n
                  .--------------.
                 /               |
>--- CUrrent ---*--- dbname n ---+--->


The DEFER command makes a database deferred or non-current.
A MDB can contain up to 1000 DBs, and any number of the 1000 DBs can be described as current and accessed at one time. Databases which cannot be accessed are described as non-current or deferred.
Makes the databases PIPING/PIPING-A and PIPING/PIPING-C deferred.
CURRENT EXCHANGE
DEFER PIPING/PIPING-A PIPING/PIPING-C
    Makes the databases PIPING/PIPING-A and PIPING/PIPING-C deferred.
DEFER PIPING/PIPING-A PIPING/PIPING-C
    Makes the databases PIPING/PIPING-A and PIPING/PIPING-C deferred.
DEFER PIPING/PIPING-A PIPING/PIPING-C
                .------------.
               /             |
>--- DEfer ---*--- dbname ---+--->

DEFER
current
non-current
deferred
                .------------.
               /             |
>--- DEfer ---*--- dbname ---+--->


The DELETE command deletes unwanted inter-DB connection macros.
The DELETE command deletes inter-DB connection macros, which are created in a Design module when connections are made between elements in different databases. Such macros should normally be executed in Design, and are deleted by the system.
To protect against accidental deletion, the DELETE command cannot be abbreviated.
Deletes macro number 3
DELETE MACRO 3
Deletes macro number 3
>--- DELETE MACro n --->

DELETE
DELETE
DELETE
n