Research Division EED/Controls Software<P> Design Note #112.6<P> Epicure Distributed Database System<P> DB Report Server/UTI Specification

Research Division EED/Controls Software

Design Note #112.6

Epicure Distributed Database System

DB Report Server/UTI Specification

David M. Kline

Contents

Revisions

Below lists the revisions that have been made to the document:

V112.0
April 30, 1992 - Initial release.
V112.1
May 12, 1992 - Incorporated suggestions from RD EED/Controls group members.
V112.2
June 10, 1992 - Modified UTI routines calling sequences.
V112.3
June 25, 1992 - DB report UTI V1.0 completed.
V112.4
July 22, 1992 - Modified document to reflect the implementation more accurately.
V112.5
August 7, 1992 - Combined routines and tuned UTI.
V112.6
February 3, 1993 - Modified document to reflect requested changes.

Introduction

This document is the design specification for both the DB Report Server and its User Task Interface (UTI). The UTI is responsible for managing the communication between the report server and client applications that request searches for data in the Epicure central database. The report server is responsible for: servicing search requests made by the UTI, providing efficient access to specific device properties and attributes, and returning device DIs and other data client applications specify.

Report Server

The DB Report Server is a VAX-based process that executes on multiple nodes to distribute the request load across several sources. The report server declares itself as a network object thereby making it eligible for multiple inbound connections from local or remote nodes.

Client applications request searches by using the UTI to build a list of search keys. Search keys are a subset of device properties and attributes available from the central database . They represent properties, attributes, or components of attributes. Attribute components are individual fields which make up a device attribute and are represented as mnemonics. Search data may be specified individually or as a list of either values or fixed length strings, thus allowing clients to specify a complex search criteria.

The data returned, by default, is a list of device DIs that have satisfied the search criteria. Client applications can specify a return data list and the order of the data. The data returned is limited to the return data codes supported by the UTI and are a subset of the possible properties & attributes that may be assigned to a device. The number of devices returned is dependent on the return data size. The report server places as many devices as possible into a return buffer. Since the report server can only return so many devices in a return buffer, the client application must interact iteratively with the report server. Later sections describe the process.

The report server communicates with the UTI & client applications by using the Epicure sns_ routines. The UTI uses non-transparent DECnet to establish communication between client applications and the report server. And uses the $QIO() system service to queue I/O request packets to the network software driver to communicate search requests.

In order to access data efficiently, the report server implements a memory cache and uses the VMS paging subsystem to reference device data. The cache consists only of the search keys supported by the report server, thus reducing the memory requirements and increasing access performance. The cache is organized as an array with DIs in ascending order. At initialization, the report server determines the size of the cache and compensates for additions, thus keeping memory pages close together and reducing any overhead associated with memory expansion.

Other functions are supported by the report server to maintain a consistent view of device property and attribute information. Whenever the central database is modified , the report server receives a message to modify the cache. The report server uses a binary search algorithm to locate the device and modify its contents.

The report server maintains other data that may be of interest to clients. Averages and accumulators are maintained and can be acquired using the dbrpt_get_status_ptr() UTI routine. In addition, a list of users who are logged in and information about them is maintained and can be acquired by the dbrpt_get_login_ptr() UTI routine. The ``statistics'' & ``user task interface'' sections describe these routines and their calling sequences.

A file is used to log any errors that the report server may encounter while executing search requests and other VMS related exceptions . The log file contains messages for a given day and a new one is created every night. Before a new log file is created, final statistic & accumulative values are written that can be reviewed for analysis and audits.

Message Format

Client applications communicate with the report server using the UTI to build and manage message packets. The Epicure sns_ routines are used by the report server to establish itself as a network object and process inbound & outbound network messages. A typical message packet consists of SNS data management/server control, search key list that is used for searching criteria, and a return data list that specifies the data to be returned to the client. The format is described as:

Figure 2 represents the details of the SNS data management/server control portion of the message packet. The data management area contains information needed by SNS to communicate with client applications. The server control area contains fields that provide a means to access the search key and return data lists. The ``offset to search key list'' & ``offset to return data list'' fields contain values that are used to locate the lists by adding them to the beginning pointer of the message packet. The calculated pointers access search criteria and identify the return data. The last cache index field allows the report server to continue searching the cache for devices which satisfy the search criteria.

Initially, the last cache index field is set to zero. When the report server is ready to send data back to the client application, the field is set to the next cache element index. The client application can then send a request to continue the search given the search criteria. The report server uses the field as a point of reference into the cache. This process continues as long as the client application sends the message packet to the report server with the correct field value. The format of the packet is described below:

Both search and return data lists are composed of message and data packets. The packets have been organized similarly and aligned on longword boundaries to efficiently increment through memory pages.

Search Key List

The search key list is constructed as a linked list using offsets to connect individual keys. And is composed of the information needed to perform the search. The search key is a data structure consisting of members that provide: an offset to the next key, search key identifier, and the list of data used as search criteria. Figure 3 describes the data structure members:

The search key is composed of a search data list that contains the search criteria. The list is used to compare and determine whether the search criteria has been satisfied. It is organized as a linked list using offsets to connect the individual data elements. The data list format is presented in figure 4:

Return Data List

Similarly, the return data list is composed of the information the client application has specified the data to be returned and the order. Figure 5 describes the format:

Return Data Format

The data is returned to the client application as specified in the return data list. The format is dependent on the data requested and it is treated by the server as an array of records. They may be a numeric value or a string array. The size of the data returned is calculated by the data type sizes. If the client application does not specify any return data, only device DIs are returned. Consider an application that requested the name and class properties (in that order). The report server would return the following message:

The last_cache_index is used internally by the UTI to direct the report server to begin searching at the point which it left off. The count value is the number of devices returned and is place in the ret_data parameters as specified by the UTI routines.

Search Keys & Data

The report server cache contains specific device properties, attributes, or attribute components that client applications can search for and have returned for display or sorting. The data is a subset of the available properties and attributes located in the central database . The table below lists the valid properties and the mnemonics used to identify them:

Some search keys are components of device attributes and require a unique mnemonic to identify them (i.e. crate/slot). The table below lists both attributes and attribute components that can be selected:

The application must specify a property code that directs the search across multiple or individual properties. The table below lists the valid property mnemonics:

If the application wants more than just the device device index returned, a list of return data codes must be specified. The table below lists the valid return data codes:

Typically the client application specifies the search key and a list of data that the report server will use to search through the cache. When multiple search keys are specified, the report server requires that all search keys match the given device. However, the device may satisfy any of the search key data. Therefore, the report server ANDs the search keys for whatever data was specified. For example, the name search key data may be specified as ``M00*'' & ``N00*''. Any device which begins with a M00 OR N00 satisfies the condition. When individual property codes are specified, the report server ORs between them. If the search key ``crate'' was specified for both the reading or status property codes, the report server would return devices which satisfy the crate data for either property code. In the case where the property code DBRPT_C_PRP_ALL is specified, the report server will AND the data across every property.

After the client has specified the search key(s) and return data list, the appropriate UTI routine is executed to send the list to the report server. Message operations will be described in later sections.

Statistics/Accumulators

Statistics and accumulators which relate to the report server are maintained and can be acquired using the dbrpt_get_status_ptr() UTI routine . The information that the server maintains is listed below:

Startup time
- This is the time the report server started.
Server state
- Indicates the state of the server. Possible states are: DBRPT__BUSY, DBRPT__IDLE, & DBRPT__OPTWAIT.
Actual device count
- The number of devices that are presently in the cache. Initially, the count is acquired when the cache is initializing using the dbsa_ UTI routines. As device additions & deletions are made, the count will adjust accordingly.
Cache device count
- This count is the maximum number of devices that can be held in the cache.
Total logins
- This counter keeps track of how many client applications have logged in since server startup.
Current logins
- This counter indicates the number of client applications that are currently logged in.
Rating value
- Value that indicates the server eligibility for client log ons. The rating value is calculated using the machine type and the value of current_logins.
Maximum search time
- This is the maximum time it took for the report server to search through the cache (per request) in 100mS intervals.
Minimum search time
- This is the minimum time it took for the report server to search through the cache (per request) in 100mS intervals.
Node name
- Node name that the report server is running on. The data is a NULL terminated text string.
Command freq
- This indicates the frequency of the different types of commands that the report server has executed since startup.
Uptime
- This indicates the number of days, hours, minutes, & seconds the report server has been running.
Request counts
- This value indicates the number of times a search key was requested.

The return statistics data format is described in figure 7:

A feature of the UTI routines is that it can be set up to return data only once or at specified intervals. Refer to the ``User Task Interface'' section for more details.

User Login List

The report server maintains a list of users who are currently logged in. Information about the users can be acquired using the dbrpt_get_login_ptr() UTI routine . The data structure is made up of a header and a list of users who are logged in. The information contained in the header is provided below:

Node
- The current node name. Same information as in the statistics data.
Login count
- Number of currently logged in.
Login list
- List of information about users.

The user information contained in the login list is as follows:

Tcid
- Task connection identification. The is used by the Epicure sns_ services to maintain network connections.
Login time
- The time the user logged into the report server.
User name
- Name of user.
Node name
- Node name of where the client is from.

The login data formats are described in figure 8:

A feature of the UTI routines is that it can be set up to return data only once or at specified intervals. Refer to the ``User Task Interface'' section for more details.

User Task Interface

The purpose of the user task interface (UTI) is to provide a means of communication between the client applications and the report server. The UTI is responsible for establishing a connection between the client applications and a local or remote report server. The logical RDCS$DBRPT_SERVER_NODE resides in the system logical table and provides a list of nodes that are running a report server. The logical is translated until a report server is found or the list terminates. A feature of the UTI is that it performs load balancing between report servers. The dbrpt_connect() attempts to connect to all report servers listed in the connection logical and requests a rating value from them. The routine determines which report server is the most optimal to stay logged in to. All other connections are disconnected.

The UTI provides a set of routines that allows the client application to build and manage the search key and return data lists. The client application specifies the search keys and its data. The UTI enters them into an internal list. Similarly, return data is specified and the UTI enters the information into the return data list of the message packet. When the client application is finished specifying the search keys and return data, it will execute one of the dbrpt_process_*() routines that send a search request packet to the report server. The UTI will either wait until the report server replies or execute an AST routine that was specified by the client application.

In order to service multiple clients efficiently, the UTI and report server perform a handshake operation. The UTI sends a message packet to the report server which searches its cache for matching criteria. The report server returns to the client application as many devices as it can given the limitation of the network buffer size and which return data was specified. Since there are probably more devices that satisfy the criteria, the report server returns a status code that indicates that more devices can be returned. The client application sends the message packet back to the report server and it picks up where it left off. The report server returns a status code indicating that it has finished searching the cache. The client application must interact with the report server this way in order to retrieve all devices that satisfy the specified search criteria. A worst case scenario is for the report server to traverse the entire cache. Bench marks have proved that on a VAX-3XXX class machine, it takes on average 3.786 seconds.

The routines described in this section are not part of EPICURELIB presently. Refer to the section Example Program for directions on how to use the user task interface. The remainder of this section describes the calling sequences of the UTI routines.

status = dbrpt_connect( [efn
[,ast ,astprm])]

The routine executes a load balancing algorithm that places the client on the optimal report server. Each report server maintains a rating given the number of users logged in and the CPU type. The rating is updated every 500mS. The routine scans every report server for the rating and determines which report server to attach to. All remaining channels are deassigned. The completion of the load balancing is signaled by the efn parameter or the routine specified by the ast parameter.

efn:
Event flag to set when load balancing is complete. Optional unsigned shortword passed by value.
ast:
AST routine executed when load balancing is complete. Optional parameter passed by reference.
astprm:
Parameter passed to AST routine when. If this parameter is present, ast parameter must be specified. Optional unsigned longword passed by value.

status:
VMS condition code returned as a longword.

DBRPT__SUCCESS:
Success. Function completed successfully.
DBRPT__NET:
Success. Connection established.
DBRPT__OPTWAIT:
Warning. Indicates load balancing is still is progress.
DBRPT__NOLOGIN:
Fatal. Maximum logins exceeded.
Others:
From the VMS system services or DECnet.

status = dbrpt_disconnect()
This routine deallocates all buffers used to manage search request lists and deassigns the channel to the report server. No parameters are required.

status:
VMS condition code returned as a longword.

DBRPT__SUCCESS:
Success. Function completed successfully.
DBRPT__NONET:
Error. The channel to the server was closed or never opened.
DBRPT__ACTIVE:
Warning. Function can not be executed because of request list state.
Others:
From VMS $DASSGN system service & LIB$ dynamic memory routines.

status = dbrpt_initialize_list( total_search_keys)

This routine initializes the search request list. The application must call this routine before any search key setup or process routine. Additionally, it must be called after completion of a previously setup search request list. If the application is retrieving all devices, the total_search_keys parameter should be set to zero.

total_search_keys:
Anticipated number of search keys and property code combinations in the request list. Unsigned longword passed by value.
status:
VMS condition code returned as a longword.

DBRPT__SUCCESS:
Success. Function completed successfully.
DBRPT__NONET:
Error. The channel to the server was closed or never opened.
DBRPT__ACTIVE:
Warning. Function can not be executed because of request list state.
Others:
From VMS LIB$ dynamic memory routines.

status = dbrpt_add_key_data( handle, key_code, prp_code, key_data, length)

This routine adds data to a search key. Multiple calls to this routine using the same key & property code combination modifies any previous call. The number of search keys is limited by the application virtual page count, network buffer size, & the parameter passed to the dbrpt_initialize_list() routine.

handle:
Value associated with search key. Unsigned longword passed by reference.
key_code:
Search key code value. Unsigned shortword passed by value.
prp_code:
Property key code value. Unsigned shortword passed by value.
key_data:
Array of data elements used as search criteria. The code implies specific data type. For example, DBRPT_C_KEY_CLASS assumes an array of unsigned bytes, whereas DBRPT_C_KEY_NAME implies an array of fixed-length NULL terminated strings. Search key datatypes and sizes are defined in the include file epicure_inc:dbrptuti.h. Passed by reference.
length:
Length of key_data in bytes. Unsigned shortword passed by value.
status:
VMS condition code returned as a longword.

DBRPT__SUCCESS:
Success. Function completed successfully.
DBRPT__INVKEY:
Error. Invalid key passed.
DBRPT__INVLEN:
Error. Invalid data length passed.
DBRPT__INVPRP:
Error. Invalid property passed.
DBRPT__NOHNDL:
Error. No handle passed.
DBRPT__NODATA:
Error. No data passed.
Others:
From VMS LIB$ dynamic memory and internal UTI routines.

status = dbrpt_cancel_key( handle)

This routine removes a search key and compresses the internal memory where it resided. The handle is set to a zero (NULL) value.

handle:
Value associated with search key. Unsigned longword passed by reference.

status:
VMS condition code returned as a longword.

DBRPT__SUCCESS:
Success. Function completed successfully.
DBRPT__INVHNDL:
Error. Invalid handle passed.
DBRPT__NOHNDL:
Error. No handle passed.
DBRPT__NOKEY:
Error. Key has not been setup.
Others:
From VMS LIB$ dynamic memory and internal UTI routines.

status = dbrpt_get_all_devices( count, ret_data [,length
[,time])]

This routine retrieves all devices in the cache. It provides the most efficient method of returning information about all devices in the central database. If a return data list was not specified, only device DIs are returned.

count:
Number of devices returned. Unsigned shortword passed by reference.
ret_data:
Address pointer of return data. Passed by reference.
length:
Length of ret_data in bytes. Optional unsigned longword passed by reference.
time:
Retrieval time in 100mS intervals. Optional unsigned longword passed by reference.
status:
VMS condition code returned as a longword.

DBRPT__FINISHED:
Success. Device information complete.
DBRPT__MORE:
Success. Device information has returned successfully however more device are possibly available.
DBRPT__SUCCESS:
Successful completion of request.
DBRPT__INVARG:
Error. Invalid arguments passed.
DBRPT__NOARG:
Error. No arguments passed.
DBRPT__NODEVICES:
Error. No devices found.
DBRPT__NONET:
Error. The channel to the report server was closed or never opened.
DBRPT__CRASH:
Fatal. Server is crashing due to fatal error.
Others:
From VMS $QIO system service, LIB$ dynamic memory routine, and report server process.

status = dbrpt_get_more_all_devices( count, ret_data [,length
[,time])]

This routine works in conjunction with the dbrpt_get_all_devices() routine to continue retrieving all devices in the cache. It provides the most efficient method of returning information about all devices in the central database. If return data was not specified, only device DIs are returned.

count:
Number of devices returned. Unsigned shortword passed by reference.
ret_data:
Address pointer of return data. Passed by reference.
length:
Length of ret_data in bytes. Optional unsigned longword passed by reference.
time:
Retrieval time in 100mS intervals. Optional unsigned longword passed by reference.
status:
VMS condition code returned as a longword.

DBRPT__FINISHED:
Success. Device information complete.
DBRPT__MORE:
Success. Device information has returned successfully however more device are possibly available.
DBRPT__SUCCESS:
Successful completion of request.
DBRPT__INVARG:
Error. Invalid arguments passed.
DBRPT__NOARG:
Error. No arguments passed.
DBRPT__NODEVICES:
Error. No devices found.
DBRPT__NONET:
Error. The channel to the report server was closed or never opened.
DBRPT__CRASH:
Fatal. Server is crashing due to fatal error.
Others:
From VMS $QIO system service, LIB$ dynamic memory routine, and report server process.

status = dbrpt_process_wait( count, data [,length
[,time])]

This routine sends the search request to the server for processing. The routine will not return until a reply has been received from the report server.

count:
Number of devices returned. Unsigned shortword passed by reference.
data:
Address pointer of return data. Passed by reference.
length:
Size of return data in bytes. Optional unsigned longword passed by reference.
time:
Retrieval time in 100mS intervals. Optional unsigned longword passed by reference.
status:
VMS condition code returned as a longword.

DBRPT__FINISHED:
Success. Device information complete.
DBRPT__MORE:
Success. Device information has returned successfully however more devices are possibly available.
DBRPT__INVARG:
Error. Invalid argument passed.
DBRPT__NOARG:
Error. No arguments passed.
DBRPT__NONET:
Error. The channel to the report server was closed or never opened.
DBRPT__CRASH:
Fatal. Server is crashing due to fatal error.
Others:
From VMS $QIO system service, LIB$ dynamic memory routine, and report server process.

status = dbrpt_get_more_wait( count, data [,length
[,time])]

This routine can be called only if the status code DBRPT__MORE was returned after the call of the dbrpt_process_wait() or a previous call of this routine.

count:
Number of devices returned. Unsigned shortword passed by reference.
data:
Address pointer of return data. Passed by reference.
length:
Size of return data in bytes. Optional unsigned longword passed by reference.
time:
Retrieval time in 100mS intervals. Optional unsigned longword passed by reference.
status:
VMS condition code returned as a longword.

DBRPT__FINISHED:
Success. Device information complete.
DBRPT__MORE:
Success. Device information has returned successfully however more are available.
DBRPT__SUCCESS:
Successful completion of request.
DBRPT__INVARG:
Error. Invalid argument passed.
DBRPT__NOARG:
Error. No arguments passed.
DBRPT__NONET:
Error. The channel to the report server was closed or never opened.
DBRPT__CRASH:
Fatal. Server is crashing due to fatal error.
Others:
From VMS $QIO system service, LIB$ dynamic memory routine, and report server process.

status = dbrpt_process_nowait( [efn
[,ast ,astprm])]

This routine sends the search request to the server for processing and returns immediately. Data arrival is signaled either by setting an event flag as specified by the efn parameter or executing the routine specified by the ast parameter. The efn and ast parameters are optional but one or the other must be specified. Passing a zero (NULL) value is equivalent to omitting the parameter.

efn:
Event flag number set when data returns. Optional unsigned shortword passed by value.
ast:
AST routine executed when data returns. Optional parameter passed by reference.
astprm:
Parameter passed to AST routine when data returns. If this parameter is present, ast parameter must be specified. Optional unsigned longword passed by value.

status:
VMS condition code returned as a longword.

DBRPT__SUCCESS:
Success. Function completed successfully.
DBRPT__ACTIVE:
Warning. Function can not be executed because of request list state.
DBRPT__INVARG:
Error. Invalid arguments passed.
DBRPT__NOARG:
Error. No arguments passed.
DBRPT__NOLIST:
Error. No request list present.
DBRPT__NONET:
Error. The channel to the report server was closed or never opened.
DBRPT__CRASH:
Fatal. Server is crashing due to fatal error.
Others:
From VMS LIB$ dynamic memory and internal UTI routines.

status = dbrpt_get_more_nowait( [efn
[,ast ,astprm])]

This routine can be called only if the status code DBRPT__MORE was returned after the call of the dbrpt_process_nowait() or a previous call of this routine. Data arrival is signaled either by setting an event flag as specified by the efn parameter or executing the routine specified by the ast parameter. The efn and ast parameters are optional but one or the other must be specified. Passing a zero (NULL) value is equivalent to omitting the parameter.

efn:
Event flag number set when data returns. Optional unsigned shortword passed by value.
ast:
AST routine executed when data returns. Optional parameter passed by reference.
astprm:
Parameter passed to AST routine when executed. If this parameter is present, ast parameter must be specified. Optional unsigned longword passed by value.

status:
VMS condition code returned as a longword.

DBRPT__FINISHED:
Success. Device information complete.
DBRPT__MORE:
Success. Device information has returned successfully however more are available.
DBRPT__SUCCESS:
Success. Function completed successfully.
DBRPT__ACTIVE:
Warning. Function can not be executed because of request list state.
DBRPT__INVARG:
Error. Invalid arguments passed.
DBRPT__NOARG:
Error. No arguments passed.
DBRPT__NODATA:
Error. No reply message allocated.
DBRPT__NOLIST:
Error. No request list present.
DBRPT__CRASH:
Fatal. Server is crashing due to fatal error.
Others:
From VMS LIB$ dynamic memory and internal UTI routines.

status = dbrpt_add_reqdata( ret_code, length [,rec_size
)]

This routine requests specific data returned from the report server. If the routine is not called, only device DIs are returned.

ret_code:
Array of shortwords containing requested return data. Passed by reference.
length:
Length of ret_code in bytes. Unsigned shortword passed by value.
rec_size:
Return record length in bytes. Unsigned longword passed by reference.
status:
VMS condition code returned as a longword.

DBRPT__SUCCESS:
Success. Function completed successfully.
DBRPT__INVLEN:
Error. Invalid length passed.
DBRPT__INVRETDAT:
Error. Invalid return data code passed.
Others:
From VMS LIB$ dynamic memory and internal UTI routines.

status = dbrpt_get_reqdata( count, ret_data [,length
[,time])]

This routine retrieves the count and copies the data returned by the report server. These values should be read only after successful completion of the *_nowait() UTI routines.

count:
Number of devices returned. Unsigned shortword passed by reference.
ret_data:
Address pointer of return data. Passed by reference.
length:
Length of ret_data in bytes. Optional unsigned longword passed by reference.
time:
Retrieval time in 100mS intervals. Optional unsigned longword passed by reference.
status:
VMS condition code returned as a longword.

DBRPT__SUCCESS:
Success. Function completed successfully.
DBRPT__NOARG:
Error. No arguments passed.
Others:
From internal UTI routines.

status = dbrpt_get_reqdata_ptr( count, ret_data [,length
[,time])]

This routine retrieves the count and the pointer to the data returned by the report server. These values should be read only after successful completion of the *_nowait() UTI routines.

count:
Number of devices returned. Unsigned shortword passed by reference.
ret_data:
Address pointer of return data. Passed by reference.
length:
Length of ret_data in bytes. Unsigned longword passed by reference.
status:
VMS condition code returned as a longword.

DBRPT__SUCCESS:
Success. Function completed successfully.
DBRPT__NOARG:
Error. No arguments passed.
Others:
From internal UTI routines.

status = dbrpt_cancel_reqdata()

This routines clears the return data list and initializes it to return device DI's only.

status:
VMS condition code returned as a longword.

DBRPT__SUCCESS:
Success. Function completed successfully.
Others:
From VMS LIB$ dynamic memory and internal UTI routines.

status = dbrpt_get_login_ptr( ctl, repcnt, stsref, login_data [,efn
[,ast ,astprm])]

The routine requests user login information from the report server as specified by the ctl parameter. The repcnt parameter specifies the interval at which the data will be returned. If the parameter is zero, the data is returned immediately and once. If the parameter is a positive non-zero value, the data is returned at the interval specified (i.e. 2 is two seconds). The stsref parameter is the location of the completion status, reference counter, and the node that has returned its data. Return data is signaled by either efn, or ast parameters. The astprm parameter is a value which is passed to the routine specified by the ast parameter. The efn and ast parameters are optional but one or the other must be specified. Passing a zero (NULL) value is equivalent to omitting the parameter. It is not required to execute the routine dbrpt_connect(), all network connections are maintained separately from search requests. Therefore, search requests and login data may be acquired simultaneously.

ctl:
This parameter controls where the data will be acquired. Presently there are two valid symbols: DBRPT_C_USE_LOGICAL & DBRPT_C_USE_DATAFILE. The first tells the routine to connect to all report servers as specified by the connection logical. The logical may reside in either the process or system name tables. The routine will search the process name table first then the system. The other specifies to use the logical that points to a data file that contains a list of all VAX nodes running report servers. Unsigned shortword passed by value.
repcnt:
Repeat count. Unsigned longword passed by value.
stsref:
Address of pointer to the status/reference data structure. Passed by reference.
login_data:
Returns a pointer to a list of user logged in. Passed by reference.
efn:
Event flag number to set when data returns. Optional unsigned shortword passed by value.
ast:
AST routine to execute when data returns. Optional parameter passed by reference.
astprm:
Parameter passed to AST routine when data returns. If this parameter is present, ast parameter must be specified. Optional unsigned longword passed by value.

status:
VMS condition code returned as a longword.

DBRPT__SUCCESS:
Successful completion of request.
DBRPT__INVARG:
Error. Invalid arguments passed.
DBRPT__NOARG:
Error. No arguments passed.
DBRPT__NOAUTH:
Error. Not authorized to execute routine.
Others:
From internal UTI routines.

status = dbrpt_cancel_repeat_login()

This routine cancels the repeat read set up by the dbrpt_get_login_ptr() and must be called to stop acquiring data from the report server.

status:
VMS condition code returned as a longword.

DBRPT__SUCCESS:
Success. Function completed successfully.
DBRPT__NOAUTH:
Error. Not authorized to execute routine.
Others:
From VMS $QIO and internal UTI routines.

status = dbrpt_get_status_ptr( ctl, repcnt, stsref, stat_data [,efn
[,ast ,astprm])]

The routine requests status information from the report server as specified by the ctl parameter. The repcnt parameter specifies the interval at which the data will be returned. If the parameter is zero, the data is returned immediately and once. If the parameter is a positive non-zero value, the data is returned at the interval specified (i.e. 2 is two seconds). The stsref parameter is the location of the completion status, reference counter, and the node that has returned its data. Return data is signaled by either efn, or ast parameters. The astprm parameter is a value which is passed to the routine specified by the ast parameter. The efn and ast parameters are optional but one or the other must be specified. Passing a zero (NULL) value is equivalent to omitting the parameter. It is not required to execute the routine dbrpt_connect(), all network connections are maintained separately from search requests. Therefore, search requests and status data may be acquired simultaneously.

ctl:
This parameter controls where the data will be acquired. Presently there are two valid symbols: DBRPT_C_USE_LOGICAL & DBRPT_C_USE_DATAFILE. The first tells the routine to connect to all report servers as specified by the connection logical. The logical may reside in either the process or system name tables. The routine will search the process name table first then the system. The other specifies to use the logical that points to a data file that contains a list of all VAX nodes running report servers. Unsigned shortword passed by value.
repcnt:
Repeat count. Unsigned longword passed by value.
stsref:
Address of pointer to the status/reference data structure. Passed by reference.
stat_data:
Returns a pointer to a list of statistics. Passed by reference.
efn:
Event flag number to set when data returns. Optional unsigned shortword passed by value.
ast:
AST routine to execute when data returns. Optional parameter passed by reference.
astprm:
Parameter passed to AST routine when data returns. If this parameter is present, ast parameter must be specified. Optional unsigned longword passed by value.

status:
VMS condition code returned as a longword.

DBRPT__SUCCESS:
Successful completion of request.
DBRPT__INVARG:
Error. Invalid arguments passed.
DBRPT__NOARG:
Error. No arguments passed.
DBRPT__NOAUTH:
Error. Not authorized to execute routine.
Others:
From internal UTI routines.

status = dbrpt_cancel_repeat_status()

This routine cancels the repeat read set up by the dbrpt_get_status_ptr() and must be called to stop acquiring data from the report server.

status:
VMS condition code returned as a longword.

DBRPT__SUCCESS:
Success. Function completed successfully.
DBRPT__NOAUTH:
Error. Not authorized to execute routine.
Others:
From VMS $QIO and internal UTI routines.

status = dbrpt_get_state()

This routine returns the current state of the UTI

status:
VMS condition code returned as a longword.

DBRPT__BUSY:
Informational. UTI is processing search request.
DBRPT__IDLE:
Informational. UTI ready for next request.
DBRPT__OPTWAIT:
Warning. UTI load balancing in progress.

usage = dbrpt_get_memory_usage()

This routine returns the dynamic memory usage of the UTI.

usage:
Value indicates number of bytes used by the UTI to build search request lists and other internal data areas.

status = dbrpt_update_cache( function, device_data, [,ast ,astprm
)]

A privileged routine that is used to update the report server cache. It sends the command specified by the function parameter and the data to all report servers. Client applications that want to use this routine require the resource identifier DBRPT__ACCESS and may request it from the Epicure system management group.

function:
Function server is to execute. Unsigned shortword passed by value.
device_data:
Device update data record. Passed by reference.
ast:
AST routine to execute when complete. Optional parameter passed by reference.
astprm:
Parameter passed to AST routine when data returns. If this parameter is present, ast parameter must be specified. Optional unsigned longword passed by value.
status:
VMS condition code returned as a longword.

DBRPT__SUCCESS:
Successful completion of request.
DBRPT__INVARG:
Error. Invalid arguments passed.
DBRPT__NOAUTH:
Error. Not authorized to execute routine.
Others:
From VMS $QIO system service, LIB$ dynamic memory routine, and report server process.

The ast routine is passed two parameters, the one specified by astprm and a pointer to an array of node status. The node status is defined by the data structure ``struct DBRPT_NODE_DATA'' as declared in the header file epicure_inc:dbrptuti.h. The node status array consists of the completion status & the name of the node. The array is terminated by the status equal to zero. See the section ``Examples Application: Device updates'' for implementation details.

Example Application: Acquiring device data

This section provides an example application which retrieves devices from the report server which name property begins with ``M00''. The following DCL commands were used to build the example application:

$ CC/DEBUG/NOOPT DEMO $ LINK /DEBUG DEMO,- EPICURE_ROOT:[WORK.DBRPT.RELEASES]DBRPTUTI/LIBRARY,- RDCS$LIB:EPICURELINK/OPT

/*
 * Fermi National Accelerator
 * Research Division/EED Controls
 * Epicure Control System
 *
 * This application retrieves devices which names begin
 * which M00*. The program instructs the report server
 * to return the name, template type, and DAP type
 * properties.
 *
 * Author: David M. Kline			21-Jul-92
 *
 */

/* Include files: */ #include stdio #include ssdef #include descrip #include descrip2

#include "epicure_inc:dbrptuti.h" #include "epicure_inc:dbrptmsg.h"

#define EXIT_ON_ERROR(s) {if((s&1)==0)sys$exit(s);} #define CHECK_STATUS(s) {if((s&1)==0)lib$signal(s);}

unsigned short return_data[] = { DBRPT_C_RET_NAME, DBRPT_C_RET_TEMPLATE_TYPE, DBRPT_C_RET_DAP_TYPE }; unsigned char names[][DB_S_NAME+1] = { "M00*" };

float seconds; unsigned long sts; unsigned long handle = 0; unsigned short count;

struct { unsigned long di; unsigned char name[DBRPT_S_RET_NAME]; unsigned char tpl[DBRPT_S_RET_TEMPLATE_TYPE]; unsigned long dap_type; } (*data)[];

void ret_data();

/******************** * Main entry point * ********************/ main() { sts = dbrpt_connect( 2);

sys$waitfr( 2);

sts = dbrpt_initialize_list( 5);

sts = dbrpt_add_key_data( &handle, DBRPT_C_KEY_NAME, DBRPT_C_PRP_NONE, names, sizeof(names));

sts = dbrpt_add_reqdata( return_data, sizeof(return_data));

sts = dbrpt_process_nowait( 2, ret_data, 0);

sts = sys$hiber();

sts = dbrpt_disconnect();

printf( "Returned %d devices in %f seconds\n", count, seconds); }

void ret_data( unsigned long PRM) { unsigned long idx; unsigned long idx1; unsigned long sts; unsigned long time;

/* Get data */ sts = dbrpt_get_reqdata_ptr( &count, &data, 0, &time);

seconds = (float)time/10;

/* Finished? */ if ( sts == DBRPT__FINISHED) { for ( idx=0; idx<count; ++idx) { printf( "%x %s %s %d\n", (*data)[idx].di, (*data)[idx].name, (*data)[idx].tpl, (*data)[idx].dap_type ); }

printf( "Last of data!\n"); sys$wake( 0, 0); return; }

/* More? */ if ( sts == DBRPT__MORE) { for ( idx=0; idx<count; ++idx) { printf( "%x %s %s %d\n", (*data)[idx].di, (*data)[idx].name, (*data)[idx].tpl, (*data)[idx].dap_type ); }

/* Get more data */ sts = dbrpt_get_more_nowait( 2, ret_data, 0); return; }

/* Errors? */ if ( (sts & 1) == 0) { printf( "Errors present!\n"); sys$exit( sts); } }

Example Application: Device updates

This section provides an example application to use the dbrpt_update_cache() UTI routine.

/*
 * Fermi National Accelerator
 * Research Division/EED Controls
 * Epicure Control System
 *
 * This application is an example to request
 * updates to the report server cache. The application
 * requests data from the central database, modifies
 * the 'beamline' property, then sends the request
 * to the report server. Mainly, the example is used
 * to illustrate the parameters that are passed to the
 * 'ret_ast()' routine. In particular, the 'node_status'.
 *
 * Author: David M. Kline                       01-Feb-1993
 *
 */

/* Include files: */ #include stdio #include ssdef #include descrip #include descrip2

#include "epicure_inc:dbrptuti.h"

void ret_ast(); unsigned long di; unsigned long sts; unsigned long idx; char device_data[5000]; struct DB_BEAMLINES *beams; struct DBSA_DEV *device_record = device_data;

/******************** * Main entry point * ********************/ main() { sts = dbsa_connect_to_server(); if ( (sts&1) == 0) sys$exit( sts);

di = 4225823; sts = dbsa_report( di, device_record); if ( (sts&1) == 0) sys$exit( sts);

dbsa_disconnect_from_server();

beams = (char *)device_record + device_record->beamlines; strncpy( &beams->beamlines[0], "UPD1", 4);

sts = dbrpt_update_cache( DBRPT_C_UPD_MOD, device_record, ret_ast, 3); if ( (sts&1) == 0) sys$exit( sts);

sys$hiber(); }

void ret_ast( unsigned long prm, struct DBRPT_NODE_DATA (*node_status)[]) { static unsigned short len; static unsigned char msg[256]; static struct dsc$descriptor msg_dsc = { sizeof( msg)-1, DSC$K_DTYPE_T, DSC$K_CLASS_S, msg};

printf( "AST ROUTINE - %d\n", prm); for ( idx=0; (*node_status)[idx].status != 0; ++idx) { sys$getmsg( (*node_status)[idx].status, &len, &msg_dsc, 0, 0);

printf( "%2.2d %8.8s %*.*s\n", idx, (*node_status)[idx].name, len, len, msg); }

sys$wake( 0, 0); }

Keywords: Epicure, controls, RDCS, database, EDDS, DBSA, DBRPT, EDBS

Distribution: normal

Security, Privacy, Legal

rwest@fsus04.fnal.gov