A request library file (RLB) is a VMS file based on
a.
request library definitidn;The RLB includes:
• Any requests nam~ in therequestlibtary definition
• Any form definitions identifiec\in each request
• Any record definitions identified in each request
You use the Request Definition Utility (RDU) to build an RLB. If a definer modi-fies a request, form definition, or record definition after an RLB has been built, you must rebuild the RLB lri order to incorporate the changes into the applica-tion at runtime:
At runtime, the program can execute a request only
if
the request is in an RLB file and the RLB file has 'been opened by the program. When the program exe-cutes' a request, the request, record information, and form definition are retrieved from the RLB file, not from the CDD.TDMS Utilities
VAXTDMS provides two utilities to create, store, and :modify definitions: the IDMS Form Definition Utility (FDU) and the TDMSRequest Definition Utility (RDU).
The TDMS Form Definition Utility
The IDMS Form Definition Utility (FDU) provides all of the capabilities that the form definer needs to Create or modify form definitions and store them in the CDD .. Using the FDU foim editor that is u;,duded in theFDU, the.form definer can:
• Create a screen image of the form, including:
- Background text (text that is always displayed on the form)
- Fields (locations on the form where data can be colleCted or displayed) - Video highlights that can be activated whenever the form is displayed and!
or when a field is available for operator input
- The screenbackground (dark odight) and number of columns (80 or 132)
• Assign specific attributes, validation procedures, arid input cii-der to fields
7·9 The TDMS Request Definition Utility
The TDMS Request Definition Utility (RDU) provides all of the capabilities that the request definer needs to:
• Define and modify requests and store them in the CDD
• Define and modify request library definitions and store them in the CDD
• Build request library files
RDU includes a validation procedure to ens~e that:
• The syntax used in each request is valid
• Each form definition named in the request exists as a CDD location contain·
ing that form definition
• Each record definition named in the request exists as a CDD location contain·
ing that record definition
• The data mappings between form and record definitions are consistent with TDMS data mapping rules
RDU also creates, validates, and stores request library definitions and verifies that each request named in a request library definition exists in the CDD.
RDU is also used to build request library files (RLBs). To build the RLB file, RDU retrieves the requests named in the request library definition and the form and record information identified in each request. As output, the RDU generates the RLB in a VMS directory. When building the RLB, RDU validates each request to make sure that form and record definitions exist, that the request syntax adheres to RDU syntax rules, and that all input and output mappings are legal.
(The definer can choose to deactivate the RDU validation procedure when cre-ating or modifying requests and request library definitions. RDU always vali·
dates request library files and does not build an RLB if it detects serious errors.) In summary, the request definer uses RDU to create and modify requests and request library definitions, and to build a request library file. TDMS can execute a request only when the request (and the form and record information identi-fied in the request) is included in an RLB file. RDU provides a validation proce-dure that may be used when creating or modifying requests and request library definitions and is always used when building an RLB.
7-10 • VAX TDMSand VAXFMS
Summary - VAX TDMS Application Elements and Utilities
Form definitions describe the appearance of the screen at runtime and regulate the type of data that the terminal operator is permitted to enter at runtime.
Record definitions describe the structure of the data that is used in the applica-tion. Requests usually identify form definitions, record definitions, and the input and output mappings that take place between them. Form definitions, record definitions, and requests are stored in the Common Data Dictionary, using utilities provided by VAX TDMS and VAX CDD.
Request library definitions list the requests used in an application. A request library file (RLB) is based on the requests named in a request library definition;
the RLB includes each request and the form and record definitions named in each request. A request must be in a request library file that has been opened by the program in order to be used in a TDMS application.
At runtime, TDMS programming calls execute requests stored in RLB files. The application is controlled by the requests that the program executes and the instructions specified by such requests. Request instructions can direct TDMS to display forms, collect and! or display information, or perform conditional operations .
• Using VAX TDMS with Other Products
Other than the VMS operating system, TDMS's only prerequisite software is the VAX Common Data Dictionary. TDMS can optionally be used in conjunction with VAX DATATRIEVE, VAX DBMS, VAX RdbIVMS, and VAX ACMS, it being a prerequisite for ACMS.
The VAX Common Data Dictionary (CDD)
The CDD is the facility in which all form definitions, record definitions, requests, and request library definitions must be stored in order to be used in a TDMS application. The CDD is not used to store data.
Before generating the CDD definitions for TDMS applications (record defini-tions, form definidefini-tions, requests, and request library definitions), you should understand the structure of the CDD and know where in the CDD you should store your definitions.
In general, the CDD is organized into a hierarchy of directories, similar to VMS directories and subdirectories. Definitions used by TDMS are stored in diction-ary objects; the name of the definition indicates the path used by the CDD to locate the dictionary object. For example, a form definition named EMPLOYEE.DISPLAY.FORM is found in the CDD by following the path of (dic-tionary directory) EMPLOYEE to (dic(dic-tionary directory) DISPLAY to (dic(dic-tionary object) FORM.
7-11 Form definitions and requests are stored in the CDD using the Form Defini-tion Utility and the Request DefiniDefini-tion Utility. To store record definiDefini-tions in the CDD, use the CDD Data Definition Language (CDDL), which is included as part of the VAX Common Data Dictionary software. Examples of record definitions are shown in the VAX TDMS Sample Application Manual. For complete information concerning the use of CDDL, see the VAX Common Data Dictionary Data Definition Language Reference Manual.
Language Support
If an application program is written in VAX COBOL or VAX BASIC it can, at compile time, use the "copying" features of those languages to include record definitions directly from the CDD. Applications written in other languages must define records in the application program itself and in the CDD.
Applications can be written in any VAX native mode language that adheres to the VAX Procedure Calling and Condition Handling standard. Specific languages supported are:
VAX BASIC VAX FORTRAN VAXC VAXBLISS-32
VAX COBOL VAXPU1 VAXDIBOL VAXB\SCAL
VAXFMS
The VAX FMS Forms Management System is designed to aid in the develop-ment of application programs that use video forms. FMS manages these forms for application programs that use Digital's VT1OO- and VT2oo-compatible termi-nals. Forms defined using VAXFMS provide a programmer with the ability to use the follOwing features of those terminals:
• Individual character attributes of reverse video,bold, blinking, and underline
• Line attributes of double-width, double-height, and scrolling
• Screen-wide attributes such as 80- or 132-column lines and reverse video
• Alternate character sets including the VT100 "special graphics character set"
for line drawing
7-12 • VAXTDMSandVAXFMS
• Who Uses VAX FMS
, , "