| |
|
|
|
3 REFERENCE
This chapter contains a reference description of:
The section concerning the class library is now empty and will be filled in a next issue of the document.
3.1 Syntax for Database Description files
The following section describes in detail the syntax for the files used to define the structure of a real time database, both on a workstation or on an LCU.
The dbl tools processes these files to build the actual database. It accepts as input a "branch config file". Class definitions are automatically searched by dbl in "class description files", stored in the following standard VLT search path:
This file can use the preprocessor directive #include (3.1.4) to load explicitly other support files containing definitions for constants and macros, points and class definitions.
3.1.1 Branch config files
The "branch configuration file" describes a whole database branch and a database can be defined by loading one or more branch config files. The standard filename extension is ".db"
The file is in ASCII format and accepts all the C language preprocessor directives (cpp), in order to have conditional compilation, defines and macros.
Keywords must be printed exactly as they appear:
Naming conventions follows the VLT standard rules as defined in [1],[4],[5].
In particular for classes, points or attributes, the naming conventions defined in Rtap documentation are restricted as follows:
· Attributes and Point names follows the programming Standard naming rules for "local Variables" (see [1])
What follows is a sample "branch config files". It is placed here just to give the look and feel of the file format. In the following paragraphs the syntax of the various components will be explained in details. Section 2.10 contains other complete examples.
3.1.2 Class description files
Class definitions shall be stored externally from "branch configuration files", in order to be publicly available to all the users.
A class description file accepts all the syntactic rules that apply to "branch config files", and contains the description of a single class. It has the same name as the class, followed by the extension ".class"
The dbl will search automatically for these files in the following directories while resolving the class dependencies:
There is no points declaration.
What follows is a sample "class description file". It is placed here just to give the look and feel of the file format. In the following paragraphs the syntax of the various components will be explained in details.
3.1.3 Comments
Comments can be inserted anywhere in a branch config file or in a class description file.
A comment starts with the "//" couple of characters and will last up to the end of the line.
3.1.4 Preprocessor directives
The file format supports all the C language preprocessor (cpp) directives, as defined in Appendix A12 of the Kernighan & Ritchie[6]. This last document is the reference for these specifications. To be more precise, the preprocessor used is the one coming with the GNU workstation compiler that is part of installed VLT Software package. Tipically this preprocessor contains non K&R extensions, but these extensions should not be used and only K&R syntax is acceptable; what follows is only a list of the preprocessor directives:
With the standard preprocessor, macros are expanded on a single line and the line splicing character `\' is just used to "pretty formatting" lines, that are anyway expanded on a single line.
This makes impossible to use macros to define dbl multi-line structures, such as a full point.
In order to overcome this problem, cpp syntax has been extended adding the line break identifier:
Every time this string is found in a macro definition, a new line character is inserted in the macro expansion.
The following sample macro will expand as a full point, whose name is given as a macro's argument:
3.1.5 Branch root declaration
The first declaration inside a branch config file is the BranchRoot.
Its purpose is to define the database pathname or the root point for the branch and every point will be loaded relative to this root.
The declaration has the following format:
Where pathname is any legal database path name, optionally delimited by quotes ("). VLT naming rules state that white-space characters are not allowed in point names.
All the points to be traversed in order to reach this root from the true database root must already exist.
The default value assumed by BranchRoot is the database root ":".
Using conditional compilation it is possible to define different alternative BranchRoot points, chosen at load time.
3.1.6 General branch properties
It is possible everywhere along the file to set the default values for a number of point and attribute characteristics.
These defaults will be used while actually loading points on the database, when not specifically overwritten.
The scope of the default definition is up to a new redefinition of the same property.
This means that it is possible to change the default values along the branch config file.
Properties can be set in any order.
The syntax used to set a default property is the following:
If value is a character string containing white-space characters, it must be enclosed in double quotes.
The properties will be described in details in the paragraphs describing Class, Point and Attribute declaration.
What follows is only a raw list of the accepted properties, according to Rtap definitions.
Some of these keywords are not used by LCC but are unloaded by Rtap and are accepted as input by LCC (see [5]).
Consider for example the Residence property. It is used at Class or Point definition level to choose if the point must be handled by the Rtap database on disk or in RAM.
- points that specify explicitly in their definition or in a parent's class definition a different residence, will get the specific one and will not been affected by the default setting.
- a new global Residence property setting will assign the new default value for all the points defined after the property itself
3.1.7 Class declaration
Classes are defined in an external "class description file"; in this way they will be reusable in a different context. "Class description files" are automatically searched in the VLT standard directories or explicitly loaded with the #include preprocessor directive.
It is possible to declare classes anywhere in a branch config file. This classes will be known by the system from that point on.
A class declaration has the following syntax:
· ParentClass is the name of the parent class, i.e. of the class from which all the properties are inherited.
If a new class does not inherit from any special class, the parameter should be set to:
BASE_CLASS
There are anyway two choices available:
BASE_CLASS - Is the normal choice for a class that does not need to inherit from any special class; this implements only the basic features internally necessary for the class handling engine and automatically assign a class identifier.
<base> - Is used for special classes with no support for static attributes. The name <base> correspond to the base class of the standard Rtap's class hierarchy. These classes will not have any class support point and it is possible to assign a specific class identifier. This is usefull in order to use the class concepts and inheritance while defining/reusing standard Rtap points (see as an example the standard CCS database). Classes derived from <base> will not appear in the class tree drawn by the dbl class browser (3.3.2).
· ClassName is the name assigned to the new class. It must be a string of characters in UPPERCASE, following the VLT naming conventions for data types (see [1])
· BEGIN...END encloses the definition of general properties for the instances of that class and the definition for its attributes.
Each class can have only one parent class: the Object Oriented model implemented uses single-inheritance.
Properties inside a class declaration BEGIN...END section can be set with the usual syntax:
What follows is a description of the properties that can be defined inside a class definition. Some keywords are ignored while loading the database on an LCU, because not supported for that platform. Most keywords are not fully specified here because identical to the Rtap definition. See Rtap[7] or LCU Common Software[5] documentation for a detailed description of these keywords.
If these properties are not explicitly specified, their values are inherited from the parent class.
If no ancestor class in the hierarchy defines a property, then the value for a true point instance is determined at load time using the current default value (as defined in the "branch config file").
It will be ever possible to overload the values for these properties in the declaration of subclasses and of instances.
Attributes describe the data that will be stored inside the class instances (see 3.1.9).
A new class inherit all the attributes already defined in the parent class (and in all the anchestor classes).
The initial value and some characteristics of an inherited attribute can be changed (overloaded) in a new class or point definition. This will be explained in details in paragraph 3.1.9, while describing attribute's declaration syntax.
Consider a sample declaration for a generic SENSOR class. We suppose here that it is a basic class, not derived from any other specific class. It must de declared as a subclass of BASE_CLASS to inherit the default characteristics:
3.1.8 Point declaration
It is possible to declare points anywhere in the file (after the declaration of BranchRoot, if present).
A point is usually an instance of a class, from whom it inherits all the properties and the attributes.
It is possible to declare points that are not instance of any class (and with no class support inside) specifying NULL_CLASS as a ClassName1.
What follows is the syntax used to declare points:
The simple form is a one line short form, used do get instances of points that do not need any change with respect to the class from which they are derived.
The complete form is used when it is necessary to overload properties or attributes or to add new characteristics.
· ClassName is the name of the class from where the point must inherit its characteristics. The dbl searches the class definition between all the loaded classes (the ones defined in the branch config file itself, the classes defined in files loaded with the #include directive or the classes already loaded to resolve other dependencies) and, if necessary, looking on the VLT specific search path for a "class description file" with the same name as the class. If ClassName = NULL_CLASS, the point will be a simple Rtap point, without any support for the class concept. This last option is to be used only while porting old databases or for really simple points.
· PointName is the name to be assigned at the specific point instance. It must be a valid Rtap point name expressed relative to BranchRoot. If the pathname contains intermediate points between BranchRoot and the point itself, they must already exist.
if PointName is ":Telescope1:Enclosure:WindScreen4", the points Telescope1 and Enclosure MUST already exist.
· BEGIN...END encloses the definition of general properties for this particular instance of point and the definition for its attributes.
Properties inside a class declaration BEGIN...END section can be set with the usual syntax:
Inside a point definition the following two properties are supported in addition to all the properties that can be set in the class declaration (i.e. Residence, Categories, CEindicator, CEorder, Usage/AttributeUsage):
Alias: specifies a unique name to identify the point in the database. If not specified, the dbl will assign automatically a value that is not duplicated anywhere else in the database.
Names of classes cannot be used as aliases, since they are already used internally, except for classes derived from the <base> class, since they do not generate a class support point.
Class: Is a class indicator from 0 to 65,535. This property can be set only for points that are not instances of any class. It is generally used to setup new alarms or plot types following Rtap class conventions. It is also used by the CCS class engine: as a consequence this property cannot be manually set for points that are instances of classes. Its default value for points with no class support is 0.
If these properties are not explicitly specified, their value is inherited from the parent class.
If no ancestor class in the hierarchy defines a property, then the value for a true point instance is determined at load time using the current default value (as defined in the "branch config file").
Attributes describe the data that will be stored inside the class instances (see 3.1.9).
A point inherit all the attributes already defined in the parent class (and in all the anchestor classes).
The initial value and some characteristics of an inherited attribute can be changed (overloaded) in a new class or point definition. This will be explained in details in paragraph 3.1.9, while describing attribute's declaration syntax.
It is possible to add new attributes to a point definition, but is a better design practice to define a new class with the required attributes and create a point as an instance of that class.
In the following example we make some instances of temperature and telemetry sensors, using the classes definitions of the previous paragraph:
3.1.9 Attribute declaration
The true description of the content of a class (or of a point) is in its attribute declarations.
Attributes describe the data that will be stored inside the point. They can be of two types:
· simple attributes, to store data of the standard database types (float, int...) [4],[5]. They will be placed on the Rtap and LCU database as standard attributes of the point.
For simple attributes three basic data structures are available:
· structured attributes, that are instances of another class, related by a "part of" relation. They will appear in the database as sub-points.
Each attribute has a unique symbolic name within the same point.
What follows is the syntax used to declare attributes:
· Simple form:
- scalar: ATTRIBUTE <Type> AttributeName [value]
- vector: ATTRIBUTE Vector AttributeName(<n.els>,<Type>)
- table: ATTRIBUTE Table AttributeName(<n.recs>,<field>,..)
- class instance: ATTRIBUTE <ClassName> AttributeName
· Complete form:
ATTRIBUTE ... simple form attribute description ...
BEGIN
... attribute description ...
END
The simple form is a one line short form, used to define attributes for which it is necessary to specify only the type and, optionally, an initial value. It should be the most commonly used and is particularly convenient with respect to the complete form.
The complete form is used when it is necessary to define or overload other characteristics of the attribute. This complete form just adds a BEGIN...END block after a definition in the simple form. In this case it is not allowed to set the attribute value on the definition line, but it can be done inside the BEGIN...END block.
A definition for a Vector or a Table can span among multiple lines, but the open round parenthesis "(" must be on the same line of the attribute name.
What follows is a description of the properties that can be defined inside an attribute declaration. Some keywords are ignored while loading the database on an LCU, because not supported for that platform. Most keywords are not fully specified here because identical to the Rtap definition. See Rtap[7] or LCU Common Software[5] documentation for a detailed description of these keywords.
Value: this property is used to specified the initial value of the attribute. It has a special syntax to specify the contents of Vectors and Tables, while the value for scalar attributes follows the standard rules.
Definition: see Rtap documentation. If CE definition is more than one line, it has to be enclosed in double quotes.
The following sub-sections analyse the different types of declarations one by one.
3.1.9.1 Scalar attributes
Scalar attributes contain a single value in any one of the allowed basic types.
· <Type> is one of the following supported types (capitalisation is ignored and the RT prefix is optional):
· AttributeName is the name to be given to identify uniquely the attribute inside the class definition or point instance
· BEGIN...END encloses the definition of general properties for this particular attribute and its value.
· [value] is an optional initial value for the attribute. If the extended format with the BEGIN...END block is used, it is not possible to set here the initial value. It can be set inside the block using the "Value" property.
Scalar attributes have a special property used to set up scan links. It will described in paragraph 3.1.9.5
3.1.9.2 Vector attributes
Vectors are uni-dimensional arrays with up to 65535 scalars of the same type; element numbers start with 0. Vector size is determined once at loading time.
· AttributeName is the name to be given to identify uniquely the attribute inside the class definition or point instance
· <n.els> is the vector size, i.e. the number of elements that will be possible to store in the Vector. It must be an unsigned integer between 0 and 65535.
· <Type> is to define the type of the elements to be stored inside the vector attribute. It is one of the supported scalar types (see previous paragraph):
· BEGIN...END encloses the definition of general properties for this particular attribute and its value.
The property Value is used to initialize the scalar elements stored inside the vector. It is defined using the following syntax:
Value (el1, el2, el3....)
The values for the elements are put in a list enclosed in round parentheses and comma-delimited. The list can be split on several lines, but the open round parenthesis "(" must be on the same line of the keyword "Value".. The elements values are set from element 0 up to the last one in the list. It is not necessary to initialize all the <n.els> components of the Vector. Not initialized elements are given the default value for their type.
In the following example we declare a vector attribute to store strings for the days of the week and we also initialize the vector:
It is also possible to automatically assign initial values to elements from a starting element. The syntax is:
In the following example we declare a vector to be initialized from element 10 to its 20 with a specific value 33 .
3.1.9.3 Table attributes
Tables are bi-dimensional arrays with up to 65535 records (lines) of the same format; each record may have 255 fields (columns). Each field contains a scalar value. Table size (the number of records) is determined once at loading time.
· AttributeName is the name to be given to identify uniquely the attribute inside the class definition or point instance
· <n.recs> is the table size, i.e. the number of records that will be possible to store in the Vector. It must be an unsigned integer between 0 ad 65535.
· <field..> is to define the fields inside the table.
Each field is a couple <Type> <FieldName> where <Type> is one of the supported scalar types and <FieldName> is the name to be used to identify the field inside the table.
There can be up to 255 fields and the definition can occupy more than one line in the description file.
· BEGIN...END encloses the definition of general properties for this particular attribute and its value.
The property Value is used to initialize the scalar elements stored inside the table. It is defined using the following syntax:
Value ( (rec1_1, rec1_2, rec1_3,...),
(rec2_1, rec2_2, rec2_3,...),
(rec3_1, rec3_2, rec3_3,...),
.....)
The values for the records are put in a list enclosed in round parentheses and comma-delimited. A single record is a comma-delimited list, enclosed in round parentheses, with the values for its scalar fields.
The lists can be split on several lines. The record values are set from element 0 up to the last one in the list. It is not necessary to initialize all the <n.recs> records of the Table and all the fields inside a record. Not initialized elements are given the default value for their type.It is also possible to initialize the table from a starting record number and from a starting field of the record.The syntax for this is:
· [<starting field>] is an optional argument that indicates from which field does the initialization takes place.
· <record value list> is a list of table record values .Elements in the list are separated by commas.
3.1.9.4 Structured attributes
In the case of class-type attributes, the declaration is equivalent to inserting a point. As a consequence all the operations syntactically correct inside a Point declaration are allowed.
This means that inside the BEGIN...END block is possible to add attributes, overload attributes characteristics and so on.
In the following example we design a maintenance instrument. This instrument contains (as an attribute) a CCD device. The definition of this attribute has to change some characteristics of the CCD class, but we do not consider necessary to build a new sub-class of CCD (this is just an example: building a specialized sub-class makes the code reusable and more readable, and must be the preferred solution).
3.1.9.5 Scan-link setup
Additionally to the properties seen in the preceding paragraphs, the dbl supports the setup of scan-links between scalar attributes on the same or on different environments[5]. This means that the value of an attribute is kept aligned with the value of another one, usually on a remote environment.
There are two different types of scan-links:
· SRBX: data is transferred only when the source attribute value changes. In this case it is possible to define a dead-band for value change.
The selection of the method to be used for any specific situation has to be guided by performance considerations.
The setup of a scan-link is done inside the definition of properties of the attribute that wants to receive data in order to be aligned with the value of a remote counterpart.
The syntax to setup a scan-link is the following:
· ScannedAttribute is the name of the attribute from which we want to receive data. It is any legal attribute name and can contain a remote environment name.
· DeadBand (in SRBX mode) specifies the amount the remote parameter must change in order to be reported.
· ENABLE or DESABLE are optional flags used to set the initial status of the link. By default a link is ENABLED and scanning is active when the database is loaded. If a scan-link is defined DESABLED, the link is defined but no scan takes place unless it is put on ENABLED status using the proper CCS function call.
The dbl uses these informations to prepare in the root directory of the database one scan configuration file per each scan device. The files have name _LOCAL.scan for the local environment and <env>.scan for remote environments. These files contain one record per each scan link, in the following format:
<dest. attr.> <source attr.> POLL <poll time> {} {} {ENABLE | DISABLE]
<dest. attr.> <source attr.> SCAN 0.0 <dead band type> <dead band> {ENABLE | DISABLE]
The scan links defined in this way must be activated at run time using the scanConfig utility.
Optionally the db loader is able to check that all the references to attributes on the same environment or on specified remote environments already exist and are of compatible types.
3.1.9.6 "STATIC" attributes
Attributes of a point contain values to characterize the current status of that specific point. Every point has its own private copy of every attribute.
It is often useful to have attributes to describe characteristics common to all the instances of the class. In this case does not make sense to have a private copy of the attribute in each instance.
The dbl supports thus a special kind of attribute (called "static").
The following syntax is accepted inside the BEGIN...END section of a class declaration:
The only difference between this declaration and the normal one is in the presence of the "STATIC" prefix in front of the ATTRIBUTE keyword.
Access to static attributes is transparent for the user, thanks to an extension of CCS functions dbWrite() and dbRead(), and is handled by the class engine.
Static attributes cannot be overloaded in a point declaration and the dbl checks for this constraint. Since static attributes are, by definition, common to a whole class, it makes no sense to change properties or value locally for a point.
Static attributes can be overloaded in a class declaration. The new attribute's parameters will be common to all the instances of the class and of the sub-classes. Instances of anchestor classes are not affected.
The measurement units and the accuracy of a device are usually properties of a specific model of a device, declared by the vendor.
A good design practice is to have a class per each model. In this case these properties are good candidates to become STATIC attributes.
Consider for example the base class for temperature sensors. It can be redefined in the following way:
We have the following sub-classes, corresponding to a model produced by Vendor1 and two models by Vendor2:
3.1.9.7 Attribute overloading
While defining a new class or while making an instance of a new point, a number of characteristics of the attributes of the original class can be modified (overloaded).
To overload the characteristics of an attribute that already exist on the base class, it is necessary only to give a new standard definition for the attribute itself, specifying the same attribute name: every time the dbl finds an attribute with the same name of another one defined in an anchestor class, it tries to use the definition in order to overload the characteristics of the old one. The new values will be checked for compatibility with the old ones, replacing them if they are acceptable, generating an error if not.
Everything not specifically overloaded will assume the inherited value.
For simple attributes it is possible to overload the following properties:
and it is not allowed to modify the type of the attribute.
For Vectors and Tables it is allowed to overload the number of elements, but not the type of the elements or the record format. The record format can only be extended on the derived class as explained in 3.1.9.8
Each structured attribute can be overloaded with another one of a different class, but only if the replacement is a sub-class of the original one, i.e. if it is a specialized version of the original attribute.
The dbl takes care of checking that all the overloaded parameters are acceptable and follow these rules. If this condition is not verified, an error message is produced and the attribute declaration is rejected.
While defining a sub-class or an instance of a class that contains class-type attributes, it is allowed to overload characteristics of an attribute inside the class-type attribute itself. When there are more levels of nesting between sub-points, the attribute to be modified can be some levels down in the hierarchy of the instances.
In this case AttributeName is a database pathname relative to the base point of the class or point definition, specifying the intermediate points to reach the desired "sub-attribute". The loader checks that all the intermediate points exist and are of the correct types.
To set the value of the attribute "max" inside the speed measuring point of the motor for the telescope altitude control the following definition has to be written:
3.1.9.8 Table record overloading
The extension of the a Table record format while overloading is allowed. The special character "..." is used on the derived table definition to indicate that new fields are added to the base table record as in the following example:
CLASS BASE_TABLE DERIVED_TABLE
ATTRIBUTE TABLE someTable (0, ...,
3.1.9.9 Vectors of points, LOOP command
A series of similar type attributes can be automatically defined via the use of the LOOP command. The syntax is :
LOOP <number of attributes><attribute definition>_#
· <attribute definition>_# is the declarion of the attribute followed by the special characters "_#" which will hold the instance number, when the actual attribute instance is created.
LOOP 50 ATTRIBUTE someClass point_#
The LOOP command can be used for attribute definitions with classes and points (both simple and structured attributes), as well as points at the branchlevel. It is not allowed to have a BEGIN-END block follow a LOOP construct.
3.2 Run-time Database
The following paragraphs describe the run-time structure of the database, as can be seen examining the point configuration files or by using the Rtap database tools. Since the dbl is up to now the only tool providing class support, a minimal knowledge of the run-time database structure is necessary to interact with it. When specific tools supporting the class concept will be available, this structure will be fully hidden to the general user.
3.2.1 Database architecture
The output of dbl is a directory tree of "point config files" describing the database structure. This description is compatible with both Workstation and LCU databases and can be loaded on any of them. Subsequent calls to dbl with different "branch config files" but with the same destination root directory will build a unique merged database. In this way it is possible to build a database step by step loading a branch at a time.
The database branch generated by dbl has a point per each point described in the configuration files. Class-type attributes are expanded as true points in the database and hierarchical structures are replicated with hierarchies of points.
The database has also a number of points to support class handling and other features, like the scan system. These points are inside the branch starting with the point with alias "ccs_config". This point is a direct child of the database root. The whole branch starting with this point is maintained automatically by the dbl and by ccs functions. The following figure (already shown in the Overview) represents the general structure of the generated database.
Points that are not instance of any class are placed in the database exactly as the are defined, without any support information. The current general branch properties are used to define the default values.
3.2.2 Instance points
Points that are instances of classes are placed in the database according to the following rules:
· All the point properties are evaluated taking into account, in decreasing order of priority, the following definitions:
· all the (non static) attributes defined in the parent class and in every anchestor up to BASE_CLASS
· All the attributes properties (including calculation engine definitions) and values are evaluated (in case of overloading) taking into account, in decreasing order of priority, the following definitions:
· The Class property is automatically set by the dbl to the ID for the parent class of the point. The class ID is automatically assigned to each class by dbl and stored in the standard point with alias "class config". The "<alias>class config.names" attribute is a table with one entry per class. Each entry has 3 fields:
· The special attribute "class" is automatically set up by the dbl and has the following definition:
For more details about the "class config" point, refer to the Rtap documentation about the alarm system[7].
3.2.3 Class support points
Each class used as a base for some point in the database has a "class description point" in the class definition branch, used by the class engine. This is a database branch having root with the point describing BASE_CLASS and reproducing the hierarchy of all the classes somewhere referenced in the database.
Each "class description point" is automatically set up by the dbl with the following characteristics:
· All the point properties are evaluated taking into account, in decreasing order of priority, the definitions for the anchestor classes and the property default.
· The point has an attribute per each static attribute declared in the class definition. Each static attribute appears in the final database only once, in the support point for the class where it has been defined.
· The Class property is automatically set by the dbl to the proper class ID. The class ID is automatically assigned to each class by dbl and stored in the standard point with alias "class config".
· All the other properties get the values assigned in the class definition. For example, a class defined to have Residence = RAM will have all its instances and the class support point stored in RAM.
· The special attribute "class" is automatically set up by the dbl and has the following definition:
so that it points to the corresponding attribute of the parent class. A special case is the point for BASE_CLASS, whose definition is empty.
When loading a branch on an already existing database, the dbl can optionally check that all the classes definitions used by the new branch matches the classes with the same name already present on the DB. There will never be two definitions for the same class: if a class is already present on the database it is not modified and incoherences generate errors.
3.2.4 Scan system support
The dbl takes care of maintaining all the points used to deal with the Scan System. For more details about the database points used by the Scan System see paragraph 2.6.5 of [4]
Whenever an attribute of a point requires the set up of a scan link, dbl:
· checks if the standard
<alias>ccs_config -> scan_config -> LAN
branch is present in the database. If not, generates an error
· checks if the scan device point for the specified environment if present in the database. If not, generates an error
· adds to the scan input table of the scan device point a proper entry to set up the required scan link.
The scan_config branch cannot be generated in a full automatic way and has to be tuned taking into account the network configuration. It is described in a "branch config file" using a set of classes provided by the VLT class library and should be loaded on the database before loading any other branch requiring scan links.
3.3 Database Design Utilities
This section contains man pages of the programs available at UNIX level for the design and maintenance of the On Line database.
dbl [-c] [-ce envName] [-D name[=value]] [-I pathname] [[-lw|-ll] envName]
[-a aliasNumber] [-v0|-v1] branchFile rootDest
The dbl tool has the purpose of reading a description of a Workstation or
LCU database branch using "branch config files" and generating a directory
tree of standard "Rtap point configuration files", ready to be loaded on
a workstation or on an LCU.
Optionally it is able to actually load the database on the specified WS
or LCU and to perform consistency checks inside the target database or
within different databases referenced in the branch description to be
loaded. These checks will be performed against the database description in
terms of "Rtap point configuration files".
branchFile is the pathname for the branch configuration file that must
be loaded
rootDest is the root directory of the database description in
terms of point configuration files
-a alias specify the first alias number to be used for automatically
generated alias. If not specified, try to generate aliases
automatically from the last alias number saved in ccs_config
point
-c forces a check of all the references internal to the whole
destination database
-ce envName checks the references with the database loaded on the
specified environment (this option can be specified multiple
times)
-lw or -ll directs the dbLoader to load the database also directly
on the specified environment, respectively on a Workstation
or on an LCU
-Dname[=value] to define symbols for the preprocessor and optionally
assign them a value, as if by #define (3.1.4). This option
can appear multiple times.
-I pathname to define the search path for include files
-v0 or -v1 Level for warning messages. The default is -v1, i.e.
all the warning are catched. If -v0 is selected, some
warnings related to specific VLT formal rules are ignored.
The following environment variables (if defined) are used:
CCS_CONFIG Rtap point name to be used for the ccs_config branch.
Used during testing to put the ccs_config branch temporary
under a different name, to not interferee with the original
one.
MODROOT Used in the search path for locating
INTROOT automatically classes
VLTROOT definitions.
CC | GCC Used to locate the C preprocessor to be used.
The default is "gcc".
The following command line is used to call the preprocessor:
[$CC | $GCC] $Istr $Dstr -E -x c++
0 if everything OK
1 in case of errors
The program sends on standard output error/warning messages and
statistics concerning the work done.
Error and warning messages are in standard format:
<file name>:<line num>: [Warning|ERROR] <message>
and can be used by standard search tools (like the emacs editor) to
locate automatically the error position in the file.
- Option -lw is available only as a prototype at selected locations
internally at ESO
- Option -ll is not available
- If a branch config file containing definitions for scan devices
is loaded on an empty destination database, dbl issues an error.
This is due to the fact that scan devices are subpoints of
"ccs_config" and this point does not exist jet.
Load first the standard CCS database or an empty branch config file
or add an EMPTY "ccs_config" point to the branch config file.
- Whenever dbl loads a new branch, it creates points specific for the
branch and creates/modify points common to several brances of the
database. Among these are the point "ccs_config" and the class support
points. If these points does not exist in the target directory tree,
they are created, otherwise the new information is merged by dbl with
old one.
As a consequence, branches that pertain to the same database MUST be
loaded on the same root point, so that the dbl can merge the files.
Merging the files later by hand is a complex operation.
- If branches are loaded independently in a running database, there could
be problems with duplicated aliases. If this is the case, run again
dbl on the file that gives problems, in order to get new higher values
for the aliases (do not clean the DB directory before this!). As an
alternative solution use the -a option to define the starting point
for alias values.
- In order to define multi-line macros, it is necessary to terminate
each line of the macro with the string "-;-\" instead that with
a simple line continuation character "\".
The dblcb is an interactive tool to manipulate classe's definitions
and the classe' hierarchies, similar in concept to the class
browsers available for all object oriented programming languages.
classFile is the pathname of a class definition file to load.
By default all class definition files in the path defined
by the environment variable DBLCB_INCLUDE will be loaded
-Dname[=value] to define symbols for the preprocessor and optionally
assign them a value, as if by #define (3.1.4). This option
can appear multiple times.
-I pathname to define the search path for include files
-v0 or -v1 Level for warning messages. The default is -v1, i.e.
all the warning are catched. If -v0 is selected, some
warnings related to specific VLT formal rules are ignored.
The following environment variables (if defined) are used:
MODROOT Used in the search path for locating
INTROOT automatically classes
VLTROOT definitions.
DBLCB_INCLUDE Is a list of directories searched by default for files
CC | GCC Used to locate the C preprocessor to be used.
The default is "gcc".
The following command line is used to call the preprocessor:
[$CC | $GCC] $Istr $Dstr -E -x c++
Scans the file identified by the name 'inputFile' and filters the
file according to the following parameters :
Parameters | Keyword
____________________________________________
- envName | Name of the environment, beginning with '@'
It the outputFile is not specified, the output is displayed on the screen.
Parameters are specified with the syntax : <parameter-name>=<value>
1This option allows to define simple points and to integrate inside a "branch config file" sections of database designed before the development of the loader/unloader tools. Old database sections in the standard Rtap point config file format can be merged with the output of dbl and are fully compatible at this level.
 Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com |
| |
|
|
|
