Design Specification for the EPICURE Central Database V2.00 Research Division Controls Software Design Note 61.2

Design Specification
for the
EPICURE Central Database V2.00
Research Division Controls Software Design Note 61.2

David M. Kline

Introduction

The EPICURE Central Database is to be implemented with Digital Equipment Corporation's relational database product VAX-Rdb/VMS.

This layered product is a general purpose relational database package that maintains a single environment of software tools for storing, retrieving, changing, and protecting data. The data is maintained as two-dimensional tables in a row/column format that keeps the data organization easy to understand. The point at which the row/column intersects contains a field that represents some piece of information about a device or device template, such as the name property.

Data is stored as individual fields and are defined as a single data type. These fields will contain a piece of information describing only part of a device or of a device template. Fields may be defined as having other attributes that are for default values, verification, and formats when other layered products are used.

To declare device or template properties and attributes, individual fields are used or logically grouped together. Grouping these fields forms a VAX-Rdb/VMS relation. For example, the di property requires only one field because it is a single quantity, whereas the location property requires many fields to represent the property.

In the central database, relations were not only formed to construct properties and attributes, but for other purposes, such as:

Arranged such that the Optimized Access database could be constructed with minimal overhead.
Device overview could be accessed quickly.
Minimize relation traversal.
Eliminate repeating fields.
Share data to minimize storage requirements.

EPICURE Central, OA View, and LAL Databases

The EPICURE Central Database contains the master instance the property and attribute information for all devices and device templates. Device templates are maintained in the central database and provide a point of departure for a particular device. Templates can be created, modified, deleted, or reported by personnel who have the appropriate authority. They are also used to share property and/or attribute data with other devices using the same data record within a database relation. Templates are identified in the database by a substring located in the name property. Users and applications can retrieve all of them without requiring specific names. Devices are created by using a device template or another device and are maintained in the central database by personnel who are authorized by information in the system authorization file.

The Optimized Access database ( OA view database) is derived from the central database with a transformation algorithm that extracts and compresses the data. The OA is contained in a global section mapped to a file. Access times are reduced by allowing the VAX/VMS paging system to move portions of the OA from disk into physical memory.

The Look Aside List (LAL) allows current central database changes to be incorporated into the OA without performing an OA build each time. The LAL is identical to the OA except it contains only the devices that have been added or modified. Every morning at some predetermined time, a new OA is constructed from the central database that voids the old OA and LAL (if any exist). Information that appears in the central database may not yet be in the OA or LAL. As new devices are added and modified, the central database is updated before the OA or the LAL.

The central database is used by VAX-Rdb/VMS and other database products to produce hard copy reports about devices and device templates. Initially, the application will be written to only provide ``canned'' reports in order to establish a reporting system. In the future, the application will be augmented to support user queries of which fields they wish to use as keys into the database. Additionally, large reports will use VAX-DATATRIEVE because of its flexible ``Report Writer''. Other applications could be written to produce reports using ``C'' or FORTRAN as an application language.

Relation Definition

The EPICURE Central Database is made up of several relations, each serving an individual purpose in order to describe a device or device template completely. The database design uses one field, the di property, defined as the primary key for most of the relations. This is to alleviate some of the performance problems by reducing overhead incurred by building the OA; distributing locks on relations, pages, and records; and minimizing the database index table size. Most database accesses are to be performed by specifying the di property. However, some may use the name property in which case the device_summary relation will be accessed. The di property will then be extracted and used, where applicable, for any further database accesses.

There are some relations that do not use the di property as the primary key, most of which are ones that consist of strings for reporting purposes and for data that is shared between devices and templates. To illustrate, the beamline_code and class_code fields in the device_summary relation are foreign keys and used as primary keys into the beamline and class relations respectively. This was done to share records between multiple devices, thereby providing for a more efficient storage method, and minimize database read times.

One feature of the central database is its ability to allow multiple devices to map to the same relation record. To illustrate, suppose that a new CAMAC module was released and several hundred were to be installed in the beamline. An operator or someone with the authority would create a device template that will be used as a basis for all the new modules, thus reducing the repetition of entering the same values several hundred times. As devices are added to the database, properties and attributes which have the same values as the template are mapped to the same record as the template. This scheme was developed to provide for a quicker method of retrieving data from the central database and to build the OA efficiently.

Initially, all the shared device records are mapped to the appropriate template record. As modifications are made to the devices, records between devices may become shared. Deleting devices that have shared records in the database may require records added to the relation. Furthermore, the central database provides a limited sharing, that is, device templates can not be shared with records with other device templates, only templates and devices or devices and devices can share records.

Shared Relations

This section lists the property and attribute relations that are shared between devices and device templates. Shared relations can be either static or non-static. Relations that contains static information are ones that multiple devices map to but the data can not be changed by a user. Data can only be modified by an authorized administrator. Non-static relations are ones that multiple devices or templates can map to but can be modified by a user with the appropriate authorization. Below lists the shared property and attribute relations that can be shared.

Property relations

- The following is a list of the relations that maintain shared data records.

beamline: - This relation represents the beamline property that identifies one or more beamlines that can be associated with a particular device. Relations which map to this relation contain a field that is a bit map representing the beamline(s). The bit positions are translated into a codes that address the appropriate text string name from the beamline relation.
class: - The class property is represented by this relation and contains values that are associated with the text string of the different classes that can be assigned to a device or device template.
device_template: - The available device templates used to create devices are listed in this relation. Additionally, reports can be generated from this relation that provide a summary of the template available.
devicetyp: - Encoded device type code and modifier value used to select the device class and subtypes of particular devices. Two relations are present to provide the devicetype class and subtypes.
moduleloc: - The moduleloc property provides the text strings of the building names or enclosures where devices reside.
moduletyp: - The moduletyp property provides the text strings of the CAMAC module type.

Attribute Relations

- Below lists the attribute relations that are shared by one or more device properties.

analog_pdb: - Analog scaling pdb values as used by the device reading or setting property are provided by this relation.
bitname: - The bitnames attribute of the status property are maintained by this relation.
control_pdb: - This relation provides the scaling information for the control property.
common_constants: - The values that are used by the analog_pdb relation for common transformations.
constant_pairs: - The constant pairs ( pi and ci ) relation is provided for the intermediate and corresponding engineering units in cooperation with the analog_pdb relation.
ctlname: - The ctlnames attribute of the control property are maintained by this relation.
data_format: - This attribute identifies the data format for the property as heterogeneous, homogeneous, or scaler.
frontend_handler: - A description of the available frontend handlers are stored in this relation.
rate: - The default sample rates for normal and plot data acquisition.
read_protection: - This relation contains the read protection attribute data.
source_class: - The source_class relation contains the text string equivalents of the available frontend machines.
status_pdb: - The status_pdb consists of the scaling information for the status property.
synthetic_function: - This relation represents the function property and is comprised of text strings of the synthetic functions available.
write_protection: - This relation contains the write protection attribute data.

Protection relations

- Both the read_protection and write_protection attributes contain bits which represent either a specific area of a beamline or classification of a device

. The read_protection and write_protection attributes located in each of the property relations is represented as five longword integers. The bits within the first longword represents the beamline areas or ``domains''. The bits within the remaining four longwords represent device-classes. The protection relations were defined to provide an easy means of retrieving the domain and device-class information without accessing any other databases, thus making it easier for report generating. The data will be accessed by converting the bit position into a code and mapping it into the relation. The data will then be retrieved from the relation and either placed into a data structure or to a file. Below describes the protection_domain and protection_class relations which contain the information.

protection_domain: - The device protection domains are represented by the bit position in the first longword. The bit position identifies the code used to retrieve the text string description from the relation.
protection_class: - The protection device-classes are represented by the bit positions within the remaining four longwords. The bit positions identify the code used to retrieve the text string description from the relation.

Non-shared Relations

This section lists the property and attribute relations that are not shared between devices and device templates. Relations which are not shared provide a way of representing a device uniquely in the database. Below lists the property and attribute relations.

Property relations

- The following is a list of the relations contain unique records of devices and device templates in the central database.

control: - The control property relation contains the default attributes that are assigned to the device /template control property.
device_summary: - This relation is considered to be the main relation that is retrieved whenever one wishes to access any information about a given device or template. In the relation, the di property is defined as the primary key and the name property is defined as the secondary key. To increase the record access performance for any relation, the di property was defined as the primary key for most of the database relations and device properties and attributes were logically grouped. Using the di property acts as a common identifier between relations and minimizes relation traversal.
history: - This relation contains the history property of a device. Information from creation to deletion is maintained. Additional fields for audit trials are present which specify the user and which properties and attributes were affected during database access.
list: - This relation contains the di properties which compose a COMPOUND device or are used to chain devices together.
reading: - The reading property relation contains the default attributes that are assigned to a device/template reading property.
reading_alarm: - The reading_alarm property is represented as a thirty-two bit integer.
setting: - The setting property relation contains the default attributes that are assigned to the device/template setting property.
status: - The status property relation contains the default attributes that are assigned to the device/template status property.
status_alarm: - The status_alarm property is represented as a thirty-two bit integer.
xtext: - This relation represents the eXtended Text property that is used to expand the text property.

Attribute Relations

- Below lists the non-shared attribute relations which support the property relations.

DAPs: - The CAMAC, CAMAC mask, 116 safety system, test CAMAC, cryo, and synthetic components relations present the Data Access Packets (DAPs) that are used by the frontend machines to address a device.
display: - This attribute relation is used by the alarm properties to display alarm messages.

Statistical Relations

In addition to the property and attribute relations, other relations are present that provide statistics about the database and values that were used to generate identifiers that support the property and attribute relations. Below lists the relations that provide this function.

database_build_history: - This relation provides the elapse time, date, and serial number for the central, OA, and LAL databases.
database_values: - This relation consists of the values that identify the last di property, shared codes, last database add, modify, or delete operation date/time, and count of the different device classes.

Property Relation Details

The following sections provide a description of the relations that compose the central database. Data formats are also provided to present the actual format used in the database.

Device Summary Relation

The device_summary relation contains several fields which provide a quick review of a device. Information is retrieved by indexing the relation for the record that matches the di or name properties. If a database query is issued and the name property is specified, the di property will be extracted from this relation and used as the index for any further requests. Below are the fields that are available and the data format that defines the relation.

property_mask

- The property mask bit positions correspond with the available device properties. This field is specific to the central database and useful when a query of a device's properties is requested.

di

- The device index property field that contains the di value, EPICURE-native and compound device flags.

name

- This field represents the name property and is defined as the secondary key.

beamline_code

- The beamline code field is a value that is used to locate the text string from the beamline relation. These names also represent the ``domains'' as outlined in design note #72.

class_code

- The class code field is the numeric representation of the device class property. It is used as an index into the class relation to retrieve the text string equivalent.

text

- Descriptive text of the device.

save_restorable

- Identifies whether saved device settings are to be restored after a system failure.

location

- The location property provides the (X,Y,Z) coordinates of both the upstream and downstream ``edges'' of the device and a pair of links to the proceeding and trailing devices in Z order. The property is represented in the device_summary relation by the below fields.

X_location
Y_location
Z_location
Z_length
pitch_angle
yaw_angle
roll_angle
previous_di
next_di

devicetyp

- Encoded device type specified as a device type number and modifier number. The value maps into the devicetyp relation containing the text strings that identify them.

devicetyp_class: - Value used to select the device class such as BEND or QUAD, etc. The code also selects the symbol used to represent the device in maps on display screens.
devicetyp_subtyp: - Value represents the subtypes of a particular class of devices, such as 3Q120 quadrupole.

moduletyp_code

- Field giving the CAMAC module type.

xtext_code

- Field providing additional information describing the device.

moduleloc_code

- The moduleloc_code field is used as an index into the moduleloc relation.

devicetemplate_code

- Field identifies the device template that was used to create the device.

controller_typ

- This field is a text string of the controller_typ property.

Reading Property Relation

The reading property relation consists of fields that construct the attributes which define the reading property for a device.

di: - The device index property field is defined as the primary key.
attribute_mask: - Bit map that identifies the attributes assigned to this property.
array_offset: - Data offset for array devices only.
sourceclass_code: - Value that indexes into the source_class property relation and points to the text string equivalent.
analog_pdb_code: - The analog scaling attribute as addressed by this value.
synthetic_function_code: - This field identifies the function that is used for the transformation.
syn_device_code: - This field is the index that is used to retrieve the synthetic_constants and the synthetic_components from their respective relations.
rate_code: - This field is used to locate the properties rate attribute from within the shared rate relation.
data_format_code: - This attribute identifies the data format for the property.
size: - The data returned from the data acquisition system for the device and property. The default and maximum return data sizes.
read_protection_code: - This field is used to locate the properties read protection from within the shared read protection relation.
DAP_code: - Value identifies what DAP relation is assigned to this property.

Setting Property Relation

The setting property relation consists of fields that construct the attributes which define the setting property for a device.

di: - The device index property field is defined as the primary key.
attribute_mask: - Bit map that identifies the attributes assigned to this property.
array_offset: - Data offset for array devices only.
sourceclass_code: - Value that indexes into the source_class property relation and points to the text string equivalent.
analog_pdb_code: - The analog scaling attribute as addressed by this value.
synthetic_function_code: - This field identifies the function that is used for the transformation.
syn_device_code: - This field is the index that is used to retrieve the synthetic_constants and the synthetic_components from their respective relations.
rate_code: - This field is used to locate the properties rate attribute from within the shared rate relation.
data_format_code: - This attribute identifies the data format for the property.
size: - The data returned from the data acquisition system for the device and property. The default and maximum return data sizes.
read_protection_code: - This field is used to locate the properties read protection from within the shared read protection relation.
write_protection_code: - This field is used to locate the properties write protection from within the shared write protection relation.
DAP_code: - Value identifies what DAP relation is assigned to this property.

Status Property Relation

The status property relation consists of fields and attributes which defines the status property for a device.

di: - The device index property field is defined as the primary key.
attribute_mask: - Bit map that identifies the attributes assigned to this property.
array_offset: - Data offset for array devices only.
sourceclass_code: - Value that indexes into the source class property relation and points to the text string equivalent.
status_pdb_code: - The status scaling constants can be accessed by this value.
rate_code: - This field is used to locate the properties rate attribute from within the shared rate relation.
bit_code: - The value used to retrieve the bitnames data.
count: - Count of bits that can be retrieved by the bit_code field value.
data_format_code: - This attribute identifies the data format for the property.
size: - The data returned from the data acquisition system for the device and property. The default and maximum return data sizes.
read_protection_code: - This field is used to locate the properties read protection from within the shared read protection relation.
DAP_code: - Value identifies what DAP relation is assigned to this property.

Control Property Relation

The control property relation consists of fields and attributes which defines the control property for a device.

di: - The device index property field is defined as the primary key.
attribute_mask: - Bit map that identifies the attributes assigned to this property.
array_offset: - Data offset for array devices only.
sourceclass_code: - Value that indexes into the source class property relation and points to the text string equivalent.
control_pdb_code: - The control scaling constants can be accessed by this value.
rate_code: - This field is used to locate the properties rate attribute from within the shared rate relation.
ctl_code: - The value used to retrieve the ctlnames data.
ctl_merge: - A flag that identifies that the ctlnames are mergeable.
count: - Count of ctls that can be retrieved by the ctl_code field value.
data_format_code: - This attribute identifies the data format for the property.
size: - The data returned from the data acquisition system for the device and property. The default and maximum return data sizes.
write_protection_code: - This field is used to locate the properties write protection from within the shared read protection relation.
DAP_code: - Value identifies what DAP relation is assigned to this property.

List Property Relation

The list property relation consists of a list of di properties which makeup a COMPOUND device or used to chain devices together. When a request is made to retrieve the list property of a device, the di property is used to access all the relation records that are associated with that device. Below provides is a list of the fields used to define this relation.

di: - The device index ( di property) used as the primary index into this relation.
list_di: - List property di property.

History Property Relation

The history property relation is used as a way to identify the operations that have been performed on a particular device. The fields that makeup the relation are provided below.

di: - The device index di property used as the primary index into this relation.
history_id: - This field is used as a way to uniquely identify a record within the relation.
user_name: - Identifies the user that performed the function on the database.
database_operation: - Database operation performed, such as add, modify, or delete.
properties_modified: - Identifies the properties that were modified during the transaction.
reading_attributes_modified: - Identifies the reading property attributes that were modified during the transaction.
setting_attributes_modified: - Identifies the setting property attributes that were modified during the transaction.
status_attributes_modified: - Identifies the status property attributes that were modified during the transaction.
control_attributes_modified: - Identifies the control property attributes that were modified during the transaction.
reading_alarm_attributes_modified: - Identifies the reading alarm property attributes that were modified during the transaction.
status_alarm_attributes_modified: - Identifies the status alarm property attributes that were modified during the transaction.
transaction_time_stamp: - Provides the data and time of when the transaction took place.
history_string: - Provides space for text to explain the transaction.

Beamline

The beamline property relation consists of a list of beamlines which can be associated with a particular device. Below provides a list of the fields within this relation.

beamline_code: - The code that is used as the primary index to access records within this relation.
count: - Count of devices that are attached this record.
beamline_name: - Text string name of the beamline.
beamline_text: - Text string describing the beamline.

Devicetyp

The devicetyp property is represented by using two relations that contain the devicetyp class and subtyp text strings for devices and device templates.

Devicetyp/Class

The devicetyp class relation consists of text strings identifying the available device classes that are for devices and device templates. Below provides a list of the fields for this relation.

devicetyp_class_code: - Value used to access the devicetyp class text string.
count: - Count of devices that are attached this record.
devicetyp_class_text: - Text string describing the class.

Devicetyp/Subtyp

The devicetype subtype relation consists of text strings identifying the available device subtypes that are for devices and device templates. Below provides a list of the fields for this relation.

devicetyp_subtyp_code: - Value used to access the devicetype subtype text string.
count: - Count of devices that are attached this record.
devicetyp_subtyp_text: - Text string describing the subtype.

Moduletyp

The moduletyp relation consists of a list of CAMAC devices which are available for devices and device templates. Below provides a list of the fields within this relation.

moduletyp_code: - The code that is used as the primary index to access records within this relation.
count: - Count of devices that are attached this record.
moduletyp_text: - Text string describing the moduletyp.

Moduleloc

The moduleloc relation consists of a list of the building names and service buildings which are available for devices. Below provides a list of the fields within this relation.

moduleloc_code: - The code that is used as the primary index to access records within this relation.
count: - Count of devices that are attached this record.
building_name: - Text string of the building.
building_text: - Text string describing the building. This field is mainly for reporting purposes.

Reading Alarm

The reading alarm relation is currently undefined and represented as a 32 bit integer. Below is the current representation in the database.

di: - The code that is used as the primary index to access records within this relation.
data: - Data to be expanded when defined further.

Status Alarm

The status alarm relation is currently undefined and represented as a 32 bit integer. Below is the current representation in the database.

di: - The code that is used as the primary index to access records within this relation.
data: - Data to be expanded when defined further.

Xtext

The xtext property relation is currently unused but is implemented in the central database. Below provides a list of the fields within this relation.

xtext_code: - The code that is used as the primary index to access records within this relation.
count: - Count of devices that are attached this record.
xtext_text: - Text string describing the property.

Attribute Relation Descriptions

The attribute relations and fields that would always be associated with a property are encapsulated by that property relation. This was done to minimize the number of relation retrieval needed to access some information. Identified in this section are the attribute relations which were not incorporated in a property relation. In addition, data formats are provided after the field definitions.

Analog PDB

The analog_pdb relation contains the scaling values. It is accessed by only the reading and setting properties using the analog_pdb_code field. Devices and device templates can map to the same record allowing records to be shared between multiple devices. The common constants and constant pair values are retrieved by other relations using the common_constants_code and constant_pairs_code field. The following is a list of the fields located in the relation.

analog_pdb_code: - Value used to retrieve the analog pdb from the database.
count: - Count of devices that are assigned to this data record.
pdb_flgs: - Consists of the idl, ee, ds, ls, and mc flags.
pdb_extended_flgs: - Extended flags for future use.
primary_units: - Primary transformation units.
common_units: - Common transformation units.
common_constants_code: - Value used as an index to access the common transformation constants.
constant_pairs_code: - Value used as an index to access the intermediate and corresponding engineering constants for interpolation.

Common Constants Relation

The common_constants relation is used by the analog_pdb (scaling) relation for the common transformation values. Below lists the fields that compose the relation.

common_constants_code: - Value used to retrieve the constants from the database.
count: - Provides a count of the constants values used in the relation.
constant_1: - Common constants #1.
constant_2: - Common constants #2.
constant_3: - Common constants #3.
constant_4: - Common constants #4.
constant_5: - Common constants #5.
constant_6: - Common constants #6.
constant_7: - Common constants #7.
constant_8: - Common constants #8.
constant_9: - Common constants #9.
constant_10: - Common constants #10.

Constant Pairs Relation

The constant_pairs relation is used by the reading and setting relations to provide the primary and common transformation values. Below lists the fields that compose the relation.

constant_pairs_code: - Value used to retrieve the constant pairs from the database.
count: - Provides a count of the pi and ci values used in the relation.
pi_1, ci_1: - Constant pair #1.
pi_2, ci_2: - Constant pair #2.
pi_3, ci_3: - Constant pair #3.
pi_4, ci_4: - Constant pair #4.
pi_5, ci_5: - Constant pair #5.
pi_6, ci_6: - Constant pair #6.
pi_7, ci_7: - Constant pair #7.
pi_8, ci_8: - Constant pair #8.
pi_9, ci_9: - Constant pair #9.
pi_10, ci_10: - Constant pair #10.
pi_11, ci_11: - Constant pair #11.
pi_12, ci_12: - Constant pair #12.
pi_13, ci_13: - Constant pair #13.
pi_14, ci_14: - Constant pair #14.
pi_15, ci_15: - Constant pair #15.
pi_16, ci_16: - Constant pair #16.
pi_17, ci_17: - Constant pair #17.
pi_18, ci_18: - Constant pair #18.
pi_19, ci_19: - Constant pair #19.
pi_20, ci_20: - Constant pair #20.
pi_21, ci_21: - Constant pair #21.
pi_22, ci_22: - Constant pair #22.
pi_23, ci_23: - Constant pair #23.
pi_24, ci_24: - Constant pair #24.
pi_25, ci_25: - Constant pair #25.
pi_26, ci_26: - Constant pair #26.
pi_27, ci_27: - Constant pair #27.
pi_28, ci_28: - Constant pair #28.
pi_29, ci_29: - Constant pair #29.

Source Class

The source_class attribute relation is used to identify the data source for a device or the default name for a device template. Below lists the fields that compose the relation.

sourceclass_code: - Value used to retrieve the data source from the database.
count: - Count of devices assigned to the data source.
datasource_name: - Text string name of the data source.

Control PDB

The control_pdb attribute relation provides the control property scaling values. Below is a list of the fields that makeup the relation.

control_pdb_code: - Value used to retrieve the pdb from the database.
count: - Count of devices assigned to the data record.
pdb_flgs: - Operational flags and options consisting of the defined attributes and mergeable flags.
mask_1: - Bit masks for operations.
mask_2
mask_3
mask_4
mask_5
mask_6
mask_7

Status PDB

The status_pdb attribute relation provides the status property scaling values. Below is a list of the fields that makeup the relation.

status_pdb_code: - Value used to retrieve the pdb from the database.
count: - Count of devices assigned to the data record.
pdb_flgs: - Operational flags and options consisting of the defined attributes, alternate char/color codes, invert, idl, and ee flags.
mask_1: - Bit masks for operations.
mask_2
mask_3
mask_4
mask_5
achar_11, color_11; achar_12, color_12: - Display character and color code alternates for 0/1 states.
achar_21, color_21; achar_22, color_22
achar_31, color_31; achar_32, color_32
achar_41, color_41; achar_42, color_42
achar_51, color_51; achar_52, color_52
on_text_1: - Text strings for ``on/good''.
on_text_2
on_text_3
on_text_4
on_text_5
off_text_1: - Text strings for ``off/bad''.
off_text_2
off_text_3
off_text_4
off_text_5

Data Format

The data_format attribute relation identifies the property as a scalar, homogeneous, or heterogeneous device. Below is a list of the fields that makeup the relation.

data_format_code: - Value used to retrieve the data record.
count: - Count of devices assigned to the data record.
data_format_name: - Text string of the data_format attribute.

Frontend Handler

The frontend_handler attribute relation provides a description of the available frontend device handlers. The frontend_handler_code value is located in the DAP relations. Below lists the fields that makeup the relation.

frontend_handler_code: - Value used to retrieve the data record.
count: - Count of devices assigned to the data record.
frontend_handler_name: - Text string of the frontend_handler_name attribute.

Rate

The rate attribute relation provides the property relations with the rate values. Below lists the fields that makeup the relation.

rate_code: - Value used to retrieve the data record.
count: - Count of devices assigned to the data record.
default_rate: - Non-plotting data acquisition.
plot_start: - Start of plotting.
plot_stop: - End of plotting.
plot_rate: - Plotting rate.
plot_maxsize: - Maximum allowed plotting rate.

Read Protection

The read protection attribute relation provides the property relations with the read protection bit masks. Below lists the fields that makeup the relation.

read_protection_code: - Value used to retrieve the data record.
count: - Count of devices assigned to the data record.
protection_1: - Protection bit masks consisting of the ``domains'' and ``device classes''.
protection_2
protection_3
protection_4
protection_5

Write Protection

The write protection attribute relation provides the property relations with the write protection bit masks. Below lists the fields that makeup the relation.

write_protection_code: - Value used to retrieve the data record.
count: - Count of devices assigned to the data record.
protection_1: - Protection bit masks consisting of the ``domains'' and ``device classes''.
protection_2
protection_3
protection_4
protection_5

Protection Domain

The protection_domain relation provides a description of the available device protection domains. It is used in conjunction with the read_protection and write_protection attribute relations to describe the device protection domains. Below lists the fields that makeup the relation.

domain_code: - Value used to retrieve the data record.
count: - Count of devices assigned to the data record.
domain_name: - Name of the domain, such as ``PW'', ``PC'', or ``MW''
domain_text: - Text string of the domain name.

Protection Class

The protection_class relation provides a description of the available device protection classes. It is used in conjunction with the read_protection and write_protection attribute relations to describe the device protection classes. Below lists the fields that makeup the relation.

class_code: - Value used to retrieve the data record.
count: - Count of devices assigned to the data record.
class_name: - Name of the class, such as ``test CAMAC''.
class_text: - Text string of the class name.

Function

The following two relations represent the function attribute used by the reading and setting properties.

Synthetic Function

The synthetic function relation consists of a list of synthetic functions which are available for synthetic devices. These may be accessed by an application program or database-o-matic application to display the synthetic functions available from the EPICURE control system. A list of the fields within this relation is below.

synthetic_function_code: - The code that is used to the access record.
count: - Count of devices that are attached this record.
function_string: - Text string of the synthetic function.

Synthetic Components Relation

The synthetic component relation consists the di and name properties for which constitutes the device.

syn_device_code: - The value used to identify the components.
count: - The count of components.
syn_component_1, ..., syn_component_5: - di components.

Synthetic Constants Relation

The constants that are used by the synthetic function are provided by this relation. Below lists the fields of this relation.

syn_device_code: - The value used to identify the constants.
count: - The count of constants used by the function.
syn_constant_1, ..., syn_constant_16: - Synthetic constants.

Bitnames

The bitnames attribute relation contains the bitnames attribute that has been assigned to the status property of a particular device. The bit_code fields has been setup to provide a primary means of retrieving the bitnames data for a particular device. Below is a list of the fields and data format of the bitname relation.

bit_code: - The value that identifies the cumulative bitnames.
count: - Count of devices attached to this bitname.
bit_number: - Bit position.
short_bitname: - The short text string that identifies the bitname.
color_0: - Color for bit = 0 state.
state_0: - The text used for a logic value of ``0''.
color_1: - Color for bit = 1 state.
state_1: - The text used for a logic value of ``1''.
long_bitname: - The long text string that identifies the bitname.

Ctlnames

The ctlnames attribute relation contains the ctlnames attribute that has been assigned to the control property of a particular device. The ctl_code fields has been setup to provide a primary means of retrieving the ctlnames data for a particular device. Below is a list of the fields and data format of the ctlname relation.

ctl_code: - The value that identifies the cumulative ctlnames.
count: - Count of devices attached to this ctlname.
ctl_seq_num: - Used to order the ctlnames and provides a means to uniquely identify them.
ctl_name: - Ctlname text string identifier.
value: - Used as a mask.

Display

The display attribute is not currently implemented. Below are the preliminary fields and data format of the relation.

di: - The di property used as the primary key.
override_di: - The di property of the override device.
logging_enable: - Logging-enabled flag.
priority: - Allows higher priority messages to be displayed.
display_text: - Text string to be displayed.

Data Access Packet ( DAP ) Relations

The Data Access Packets that are used by the front end machines to access the beamline hardware are outlined in this section. The following sections provide a list of the fields and data formats which compose the relations.

CAMAC DAP Data

di: - The di property as the primary key.
set_offset: - Offset to set data in the DAP.
frontend_handler_code: - Identifies the frontend handler used by the frontend machines.
branch: - Branch number.
slot: - Crate slot number.
crate: - Crate number.
channel: - Module channel number.
property_number: - Property number.

CAMAC Mask DAP Data

di: - The di property as the primary key.
set_offset: - Offset to set data in the DAP.
frontend_handler_code: - Identifies the frontend handler used by the frontend machines.
branch: - Branch number.
slot: - Crate slot number.
crate: - Crate number.
shift_offset: - Shift offset.
property_number: - Property number.
mask: - Operational mask.

116 Safety System DAP Data

di: - The di property as the primary key.
set_offset: - Offset to set data in the DAP.
frontend_handler_code: - Identifies the frontend handler used by the frontend machines.
branch: - Branch number.
slot: - Crate slot number.
crate: - Crate number.
channel: - Module channel number.
property_number: - Property number.
device_number: - Device number.
subcrate: - Subcrate.
subsystem: - Subsystem.

Test CAMAC DAP Data

di: - The di property as the primary key.
set_offset: - Offset to set data in the DAP.
frontend_handler_code: - Identifies the frontend handler used by the frontend machines.
property_number: - Property number.

Cryo DAP Data

di: - The di property as the primary key.
set_offset: - Offset to set data in the DAP.
frontend_handler_code: - Identifies the frontend handler used by the frontend machines.
array_offset: - Arrayoffset value.
device_id: - Device id value.
crate: - Crate number.
property_number: - Property number.
count: - Counts of defined TANs.
TAN_1,..., TAN_24: - Type, Aspect, and channel Number (TAN) values.

Database Values Relation

The database_values relation consists of fields that are used to keep track of the values that were last used by application programs. They retrieve these values when a new value needs to be generated. Furthermore, this relation keeps count of the different device classes in the central database. Below provides a list of the fields and data format that makes up this relation.

record_number: - Identifies the primary key of the relation.
beginning_di: - Value used to begin the di property.
ending_di: - Last value used to generate the di property.
devices_count: - Total count of devices in the database.
compound_device_count: - Total count of compound devices in the database.
nondevice_device_count: - Total count of nondevice devices in the database.
normal_device_count: - Total count of normal devices in the database.
softdevice_device_count: - Total count of softdevice devices in the database.
synthetic_device_count: - Total count of synthetic devices in the database.
last_analog_pdb_code: - Last analog_pdb_code value generated.
last_beamline_code: - Last beamline_code value generated.
last_bit_code: - Last bit_code value generated.
last_moduleloc_code: - Last moduleloc_code value generated.
last_constant_pairs_code: - Last constant_pairs_code value generated.
last_control_pdb_code: - Last control_pdb_code value generated.
last_ctl_code: - Last ctl_code value generated.
last_ctl_seq_num: - Last ctl_seq_num value generated.
last_data_format_code: - Last data_format_code value generated.
last_devicetemplate_code: - Last devicetemplate_code value generated.
last_devtyp_class_code: - Last devtyp_class_code value generated.
last_devtyp_subtyp_code: - Last devtyp_subtyp_code value generated.
last_frontend_handler_code: - Last frontend_handler_code value generated.
last_history_id: - Last history_id value generated.
last_moduletyp_code: - Last moduletyp_code value generated.
last_rate_code: - Last rate_code value generated.
last_read_protection_code: - Last read_protection_code value generated.
last_sourceclass_code: - Last sourceclass_code value generated.
last_status_pdb_code: - Last status_pdb_code value generated.
last_syndevice_code: - Last syn_device_code value generated.
last_write_protection_code: - Last write_protection_code value generated.
last_xtext_code: - Last xtext_code value generated.

Database Build History Relation

The database_build_history relation consists of fields that keep track of the times it took to build the central database, OA, and LAL databases. Below lists the fields that make up the relation.

record_number: - Identifies the primary key of the relation.
OA_version_number: - Version number of the OA.
OA_serial_number: - Serial number of the OA.
OA_build_date: - Date the OA was built.
OA_build_elapse_time: - Elapse time to build the OA.
LAL_version_number: - Version number of the LAL.
LAL_serial_number: - Serial number of the LAL.
LAL_build_date: - Date the LAL was built.
LAL_build_elapse_time: - Elapse time to build the LAL.
CDB_version_number: - Version number of the central database.
CDB_serial_number: - Serial number of the central database.
CDB_build_date: - Date the central database was built.
CDB_build_elapse_time: - Elapse time to build the central database.
CDB_last_backup: - Date last backup was performed on the central database.
CDB_last_db_access_time_stamp: - Date and time last central database access occurred.

Performance Issues

Improving the Central Database performance is essential for the volume of possible users. The Rdb/VMS Database Administration and Maintenance Guide outlines several relevant issues. Some of the ideas are listed below:

Database Definition: - When an Rdb/VMS database is defined two files are created, the database file and a snapshot file. The database file contains the field and relation definitions, whereas the snapshot file models the database file, and distributes the read requests for READ_ONLY transactions. It may be advantageous to place these files on individual disk drives to distribute the disk IO load. If the disk IOs become very heavy, then the snapshot file may need to be disabled.
Database Normalization: - This process is performed as part of the database definition phase. It is the optimized grouping of fields while defining relations in order to eliminate redundant fields, identify primary keys, and check for fields dependencies.
Run-Unit Journaling: - Whenever Rdb/VMS creates a transaction, a run-unit journal file is created on behalf of the user. This is used to ``unwind'' any transactions that are not wanted or if any system failure occurs. These files reside by default in SYS$LOGIN, however they can be redirected to reside in some common directory. When Rdb/VMS comes up after a system failure, all run-unit journals are located and processed; if the system(s) are taking longer than anticipated to boot, some of these files may not update the database, therefore we may need to place them in some common directory on a disk separate from the database and/or snapshot files.
After-Image Journaling: - After modifications to the database file are committed, a record of the transaction is placed into an after-image file. If a system failure occurs, this after-image file may be used to update a previous version of the database. However, disk IO contention may arise when many updates are being written to this and the database file. Therefore, the file should be located on another disk or disabled.

Security, Privacy, Legal

rwest@fsus04.fnal.gov