Programmer's ROM - The Computer Language Library/programmersrom.iso/ada/pdl/ddictusr.rno

Text File | 1988-05-03 | 33.0 KB | 1,081 lines

.title DATA DICTIONARY USER'S MANUAL
.fl bold
.fl capitalize
.c
^<^*Data Dictionary User's Manual\*\&
.sthl 7 !no run-in format
.hl1 Command Format
.hl2 CREATE__DICTIONARY Command
.lt
-- CREATE_DICTIONARY : Create a data dictionary
-- Version 2.01-1.1

procedure CREATE_DICTIONARY(
   DICTIONARY : in STRING
   );

-- DICTIONARY : Full directory name of dictionary to be created
.el
.hl2 EDIT__DICTIONARY Command
.lt
-- EDIT_DICTIONARY : Call the interactive dictionary editor
-- Version 2.01-1.1

type TEMPLATE_NAME is (OBJECT_DECL, TYPE_DECL, PROCEDURE_DECL, FUNCTION_DECL,
                       PACKAGE_DECL, TASK_DECL, EXCEPTION_DECL);

procedure EDIT_DICTIONARY(
   DICTIONARY : in STRING;
   TEMPLATE   : in TEMPLATE_NAME;
   IDENTIFIER : in STRING        := ""
   );

-- DICTIONARY : Full directory name for dictionary
-- TEMPLATE   : Type of template to edit
-- IDENTIFIER : Name of dictionary entry
.el
.hl2 UPDATE__DICTIONARY Command
.lt
-- UPDATE_DICTIONARY : Update data dictionary
-- Version 2.01-1.1

procedure UPDATE_DICTIONARY(
   DICTIONARY   : in STRING;
   COMMAND_FILE : in STRING
   );

-- DICTIONARY   : Full directory of dictionary to be updated
-- COMMAND_FILE : Command file containing update directives
.el
.hl2 REPORT__DICTIONARY Command
.lt
-- REPORT_DICTIONARY : Produce report from data dictionary
-- Version 2.01-1.1

type REPORT_NAME is (SUMMARY, FULL, COMMAND_FILE);

procedure REPORT_DICTIONARY(
   DICTIONARY : in STRING;
   REPORT     : in REPORT_NAME := SUMMARY;
   ENTRIES    : in STRING      := "";
   ENTRY_FILE : in STRING      := "";
   OUTPUT     : in STRING      := ""
   );

-- DICTIONARY : Full directory name of dictionary to report
-- REPORT     : Which kind of report to produce
-- ENTRIES    : Entries in dictionary from which to produce report
--              (If Entries = "" and Entry_File = "" then entire
--              dictionary is reported on)
-- ENTRY_FILE : File containing entries in dictionary on which to report
-- OUTPUT     : Output file for report (default is standard output)
.el
.hl1 Description
.hl2 Introduction
.p
The data dictionary provides a means of entering and updating incomplete
Ada declarations.  Before any of the other operations listed above in Section 1
may be performed,
the user must create a data dictionary with the CREATE__DICTIONARY command.
After a dictionary is created, the other commands given above may be issued.
The EDIT__DICTIONARY command provides an interactive means of entering and
updating dictionary entries.  The UPDATE__DICTIONARY command allows the user to
enter and update items in the dictionary in a non-interactive mode.  Finally,
the REPORT__DICTIONARY command allows the user to obtain different reports on
the entries in the dictionary.  The command format for any of the data
dictionary tools may be obtained by invoking the tool with no parameters.
Each command is described in detail below.
.pg
.hl2 Creation \of \a Data Dictionary
.b
.lt
-- CREATE_DICTIONARY : Create a data dictionary
-- Version 2.01-1.1

procedure CREATE_DICTIONARY(
   DICTIONARY : in STRING
   );

-- DICTIONARY : Full directory name of dictionary to be created
.el
.p
Creates a new data dictionary with the name DICTIONARY__NAME.  For example,
entering the command
.b
.lt
    CREATE_DICTIONARY("[.mydict]");
.el
.b
on a VMS system
would create a data dictionary with the name "mydict.dir" in the current
directory.  Note that the "[]" notation for file specifications in this example
is the VMS directory specification notation.  On another system, the notation
appropriate for directory specifications on that system should be used.
.hl2 Interactive Data Entry \and Editing
.b
.lt
-- EDIT_DICTIONARY : Call the interactive dictionary editor
-- Version 2.01-1.1

type TEMPLATE_NAME is (OBJECT_DECL, TYPE_DECL, PROCEDURE_DECL, FUNCTION_DECL,
                       PACKAGE_DECL, TASK_DECL, EXCEPTION_DECL);

procedure EDIT_DICTIONARY(
   DICTIONARY : in STRING;
   TEMPLATE   : in TEMPLATE_NAME;
   IDENTIFIER : in STRING        := ""
   );

-- DICTIONARY : Full directory name for dictionary
-- TEMPLATE   : Type of template to edit
-- IDENTIFIER : Name of dictionary entry
.el
.pg
.hl3 Description
.p
Entries in the data dictionary may be entered and updated by
selecting and editing on-screen template forms.  The editor provides templates
for declarations of the following:
.lm27
.b
OBJECT__DECL
.br;TYPE__DECL
.br;PROCEDURE__DECL
.br;FUNCTION__DECL
.br;PACKAGE__DECL
.br;TASK__DECL
.br;EXCEPTION__DECL
.b
.lm0
Each
template fits on one screen.  The exact appearance of each template can be
found in Appendix A.  The user enters new data by selecting a template
and filling out the fields (shown on the screen enclosed by angle brackets)
using the editing
commands described below.  Existing dictionary entries
may be updated by selecting an entry, which is defined by a template type
and an
identifier, and using
editing commands to change it.  When an existing entry is selected, it is
displayed on the screen as a template which has been filled out.  Fields
containing the null string will be displayed as a field label enclosed
in angle brackets.
For filled out fields, the display will show the text contained
in the field.
.p
All templates contain the following three special fields: _<ident>,
_<overload> and _<syn>.
.p
The _<ident>
field, which is always the first field in the template, is the name of
the dictionary entry.  This field must always be filled out in order
to create an entry.  The name which appears in the _<ident> field, when
specified in conjunction with a template type, identifies the entry
for all the data dictionary tools.
.p
Entries in the dictionary may be overloaded.  If more than one entry of
a particular template type has the same name (_<ident>), the _<overload> field
distinguishes each instance of the name.  Therefore, the _<overload> field
must be filled out in order to create more than one entry of a particular
template type with the same name.
The _<overload> field should contain a short
explanation of what makes this entry unique from the other entries
with the same _<ident>,
rather than a description of the  _<ident>.
.p
The _<syn> field
also appears in every template.  This field is used
to express that this entry is a synonym for an Ada declaration
which has already been coded, although the Ada declaration
might have a different name.
For example, one might have a TYPE__DECL entry called "Tree__Type" in the
dictionary which corresponds to a type declaration called "Labeled__Tree" in an
Ada subprogram.  One could enter "Labeled__Tree" in the _<syn> field for
the dictionary entry "Tree__Type" in order to show that the two refer to
the same data structure.
.hl3 Editing Commands
.p
Editing commands may be entered at the field prompt.  Only enough of a command
to distinguish it from other commands must be typed.  The list of commands is
given below, followed by a detailed description of each command.  In the
description of each command, square brackets "[]" indicate an optional part
of the command, capital letters and special characters indicate literal
commands that the user must type,
and small letters indicate user-supplied input.  The commands are as follows:
.b
.lm20
ED[IT] template-type [identifier]
.br;+&nL[INES]
.br;-&nL[INES]
.br;&nL[INE]
.br;+&n[FIELDS]
.br;-&n[FIELDS]
.br;&nF[IELD]
.br;_<fieldname>
.br;_&text
.br;/oldstring/newstring[/]
.br;H[ELP]
.br;CR[EATE]
.br;U[PDATE]
.br;D[ELETE] template-type identifier
.br;S[HOW] template-type identifier
.br;EX[IT]
.br;CO[MMANDS]
.br;R[EFRESH]
.b
.lm0
.p
Occasionally, messages are displayed on the screen.
The message line is the last line on the screen.
There are four types of messages: messages prefixed by "INFO:" are just
informational messages,
messages prefixed by "ERROR:" are error messages and indicate that the
command typed could not be completed successfully,
messages prefixed by "HELP:" indicate what should be typed into a particular
field,
and messages prefixed by "WARNING:" are warnings to the user that although the
command typed was completed successfully, the result may not be what was
intended.
.hl4 ED[IT] \template-type [identifier]
.p
Displays a template on the screen for editing.
If only the ^&template-type\& is
given, an empty template is displayed on the screen.  If both ^&template-type\&
and ^&identifier\& are given, a template filled out with the data corresponding
to ^&identifier\& is displayed.
If the user requests a ^&template-type\& and ^&identifier\& which is overloaded
(see Section 2.3.1),
a list of the overloads is displayed as a numbered menu from which
the user may select the desired entry.
This command is
functionally similar to invoking the editor from the command line
(see Section 2.3.3).
The prompt when a template is first displayed appears as:
.b
.lt
<ident>:
.el
.b
While editing, the prompt always indicates the current field.
.p
The next six commands are used to move around (change the current field)
within the template.  For these commands,
&n is a numeric argument which defaults to 1 if not explicitly specified.
The user cannot go beyond the first field on the screen or the
last field on the screen (i.e. there is no "wraparound.")
.hl4 +&nLINES
.p
The first field on the line &n lines
from the current line becomes the current field.
.hl4 -&nLINES
.p
The first field on the line &n lines
from the current line becomes the current field.
.hl4 &\nLINE
.p
The first field on the &nth line on the screen becomes
the current field.  If &n is larger than
the number of lines, the first field on the last line becomes the current field.
.hl4 +&n[FIELDS]
.p
The field &n fields from the current field becomes the current field.
A carriage return may be used instead of +1[FIELDS] in order to move to
the next field.
.hl4 -&n[FIELDS]
.p
The field &n fields before the current field becomes the current field.
.hl4 &\nF[IELD]
.p
The &nth field becomes the current field.
If &n is larger than the number of fields, the last field becomes the
current field.
.hl4 _<fieldname>
.p
^&Fieldname\& becomes the current field,
if ^&fieldname\& exists.  Otherwise, the current field does not change.
The exact fieldname must be entered.
.hl4 _&text
.p
Enters ^&text\& into the current field.
If the field is already filled out, it is overwritten.  A
carriage return terminates ^&text\&.
Omitting the ^&text\& inserts the null string into the current field.
The current field becomes the next field after insertion.
.hl4 /oldstring/newstring[/]
.p
Substitutes newstring for oldstring in the current
field.  If one of the strings contains a "/" it must be
escaped by a "_'".  The escape character "_'" may also be escaped by
itself ("_'_'").  For example, to change the text "3/25/85" to
"3.25.85" the command "/3_'/25_'/85/3.25.85" would be entered.  To change
the text "a_'b" to "ab" the command /a_'_'b/ab/ would be entered.  The
closing "/" is optional.
.hl4 H[ELP]
.p
Displays help for the current
field.  There is a help message associated with each field
in the template, and it consists of one line describing what should be entered
in that field.
.hl4 CR[EATE]
.p
Creates a new entry from the current template.
If an entry with this name already exists, the user must fill
out the _<overload> field in order that a new declaration with the same
name is entered into the dictionary.  Note that what to enter into this field
is up to the discretion of the user, as the EDIT__DICTIONARY tool does not
enforce that two overload
fields must be different.
.hl4 U[PDATE]
.p
Updates the dictionary entry being edited by saving any changes made.
.hl4 D[ELETE] \template-type \identifier
.p
Deletes data dictionary entry ^&identifier\& of type
^&template-type\&.  If there is more than one entry with this name, the user
must select the entry desired from a numbered menu which lists the contents
of the _<overload> field for each instance of the ^&identifier\&
in the dictionary.
.hl4 S[HOW] \template-type \identifier
.p
Displays a list of all the entries with name ^&identifier\& for
^&template-type\& along with the _<overload> field for each.
.hl4 EX[IT]
.p
Exits from the data dictionary editor.  If the current template has been
modified, the user is prompted for whether or not to save the changes.
.hl4 CO[MMANDS]
.p
Displays a list of all editing commands and available template types.
.p
.hl4 R[EFRESH]
.p
Refreshes the display on the screen.  This command is useful to get rid
of extraneous characters on the screen.
.hl3 Examples
.p
The editor is invoked with the EDIT__DICTIONARY command, whose format is given
in Section 2.3.
If IDENTIFIER => "" (the default), then a blank template of the type given in
the TEMPLATE parameter is displayed on the screen.
Otherwise, a template filled out
with the information corresponding to IDENTIFIER is displayed.
For example, the command
.b
.lt
    EDIT_DICTIONARY("[.mydict]", FUNCTION_DECL, "abc");
.el
.b
specifies that the function declaration called abc in dictionary [.mydict]
is to be
edited.  The editor is invoked and the dictionary entry for function
declaration abc is displayed on the screen as a filled out function template.
If function abc does not exist, a warning message is given and a blank
template, with _<ident> field filled out as abc is displayed on the
screen for the user to edit.
.b
The command
.b
.lt
    EDIT_DICTIONARY("[.mydict]", FUNCTION_DECL);
.el
.b
would result in displaying the following screen:
.b
.lt
Function Declaration

function <ident>                   ( -- <overload>
    <1.param>                        -- <1.comm>
    <2.param>                        -- <2.comm>
    <3.param>                        -- <3.comm>
    <4.param>                        -- <4.comm>
    ) return <type>

-- Synonym: <syn>
-- <date>                       <author>

-- <1.desc>
-- <2.desc>
-- <3.desc>
-- <4.desc>
-- <5.desc>
-- <6.desc>
-- <7.desc>
-- <8.desc>


<ident>:

.el
.b
At this point, the user might want to delete object declaration b from the
dictionary.  He would enter the following command at the prompt:
.b
.lt
<ident>: delete object_decl b
.el
.pg
If more than one occurrence of object declaration b appears in the dictionary,
the user will be presented with a menu, such as the following:
.b
.lt
Overloads for OBJECT_DECL b

 1 : takes string parameter
 2 : takes string_type parameter


















Enter choice (* to abort):

.el
.b
When the user selects the appropriate instance of b, that instance of b is
deleted from the dictionary.
.hl2 Non-Interactive Data Entry
.b
.lt
-- UPDATE_DICTIONARY : Update data dictionary
-- Version 2.01-1.1

procedure UPDATE_DICTIONARY(
   DICTIONARY   : in STRING;
   COMMAND_FILE : in STRING
   );

-- DICTIONARY   : Full directory name of dictionary to be updated
-- COMMAND_FILE : Command file containing update directives
.el
.hl3 Description
.p
This command makes it possible to enter and update declarations in
the dictionary in a non-interactive mode.  The format for COMMAND__FILE is
specified below.  In the
description of each command's format, square brackets "[]" indicate an
optional part
of the command, capital letters and special characters indicate literal
commands that the user must type,
and small letters indicate user-supplied input.
.hl3 Command File Format
.p
Three types of commands may be entered in the command file: CREATE, UPDATE
and DELETE.  CREATE causes a new instance of
^&template-type\& ^&identifier\& to be entered into the dictionary, and
UPDATE causes a dictionary entry ^&template-type\& ^&identifier\&
to be updated (i.e. overwritten).  DELETE deletes dictionary entry
^&template\& ^&identifier\&.
.b
The format for the CREATE command is as follows:
.b
C[REATE] template-type identifier
.br;_<fieldname>contents
.br;_<fieldname>contents
.br;  .
.br;  .
.br;  .
.b
It is not necessary to have a _<fieldname>contents entry in the command
file for
each field in the template.  To fill out only one field in a template,
only one line containing that _<fieldname> and its contents
need be entered after the CREATE command.
.b
If an instance of ^&identifier\& is already in the dictionary and the
_<overload> field has not been specified, the _<overload> field
field is filled out with ^&source file name\&, ^&line number\& in order
to distinguish it from other overloads.
.b
The format for the UPDATE command is as follows:
.b
U[PDATE] template-type identifier [occurrence]
.br;_<fieldname>contents
.br;_<fieldname>contents
.br;  .
.br;  .
.br;  .
.b
As with the CREATE command, it is not necessary to have an entry for every
field in the template.
.b
If ^&template-type\& ^&identifier\& is overloaded, ^&occurrence\& may
be used to specify which occurrence to update.  ^&Occurrence\& is an integer.
.b
The format of the delete command is as follows:
.b
DELETE template-type identifier [occurence]
.b
Once again, if ^&template-type\& ^&identifier\& is overloaded,
an integer ^&occurrence\& may be used to specify which occurrence to update.
.b
WARNING: When an entry is deleted, the ^&occurrence\& number for a particular
entry may change.  For example, if there are five object declarations in the
data dictionary called "x," and the user wishes to delete occurrences one
through four, he should enter either of the following two sequences of commands
in his command file:
.b
.lt
    d object_decl x 1
    d object_decl x 1
    d object_decl x 1
    d object_decl x 1
.el
.b
.lt
    d object_decl x 4
    d object_decl x 3
    d object_decl x 2
    d object_decl x 1
.el
.b
Entering the commands
.b
.lt
    d object_decl x 1
    d object_decl x 2
    d object_decl x 3
    d object_decl x 4
.el
.b
will NOT result in deleting the first four occurrences of object declaration
x.
.hl3 Examples
.b
The command
.b
.lt
    UPDATE_DICTIONARY("[.mydict]", "commands.in");
.el
.b
would read the file commands.in and update dictionary [.mydict] accordingly.
The command file may be generated by running the REPORT__DICTIONARY tool with
REPORT => COMMAND__FILE and editing the resulting output
to form the desired command file for input to the UPDATE__DICTIONARY tool.
For example, a file containing
.b
.lt
update function_decl foo
<4.param>a : integer;
<4.comm>an example param. comment
cr type_decl t
<1.desc>An example type.
.el
.b
would specify that function foo is to be updated, changing the specified
fields, and that a new type t is to be entered.
.hl2 Data Dictionary Item Report
.b
.lt
-- REPORT_DICTIONARY : Produce report from data dictionary
-- Version 2.01-1.1

type REPORT_NAME is (SUMMARY, FULL, COMMAND_FILE);

procedure REPORT_DICTIONARY(
   DICTIONARY : in STRING;
   REPORT     : in REPORT_NAME := SUMMARY;
   ENTRIES    : in STRING      := "";
   ENTRY_FILE : in STRING      := "";
   OUTPUT     : in STRING      := ""
   );

-- DICTIONARY : Full directory name of dictionary to report
-- REPORT     : Which kind of report to produce
-- ENTRIES    : Entries in dictionary from which to produce report
--              (If Entries = "" and Entry_File = "" then entire
--              dictionary is reported on)
-- ENTRY_FILE : File containing entries in dictionary on which to report
-- OUTPUT     : Output file for report (default is standard output)
.el
.hl3 Description
.p
The report tool can produce three kinds of reports: SUMMARY, FULL and
COMMAND__FILE.  The SUMMARY report is a sorted list of data dictionary
items organized by the templates they are associated with.
The FULL report shows the actual contents of the selected dictionary entries.
The COMMAND__FILE report generates a command file which can be edited and
processed by the UPDATE__DICTIONARY command.  For all three reports, the
user may select which entries to include in the report by using the ENTRIES
and ENTRY__FILE parameters.
.hl3 Format \for Entries \and Entry__File
.p
In the
description of each format, square brackets "[]" denote optional parts and
small letters indicate user-supplied input.
.b
The ENTRIES parameter has the form:
.b
.lt
          template-type [identifier identifier ...]
.el
.b
This parameter selects the dictionary entries to include in the report.
Entries may also be selected in the file given as the ENTRY__FILE
parameter,
which contains lines which have the same format as the ENTRIES
parameter.  Both means of selection are provided so that the user can
keep a large number of selections in a file, but still select a small
number of entries on the command line.  If both ENTRIES and ENTRY__FILE
are null (""), which is the default, then all entries in the data dictionary
will be included in the report.
.hl3 Examples
.p
The REPORT__DICTIONARY command is invoked according to the format given in
section 2.5.
.b
The command
.b
.lt
    REPORT_DICTIONARY("[.mydict]", ENTRIES=>"function_decl a b xxx");
.el
.b
specifies that a summary report (the default report type) is to be generated
from the functions a, b and xxx and written on the standard
output (the default output file).
.p
If the list of identifiers (^&identifier\& ^&identifier\& ...) is omitted,
the report will contain all entries of the specified
^&template-type\&.  For example,
.b
.lt
    REPORT_DICTIONARY("[.mydict]", Entries=>"FUNCTION_DECL");
.el
.b
specifies that a summary report is to be generated for all functions in the
dictionary.
.b
The command
.b
.lt
    REPORT_DICTIONARY("[.mydict]", FULL, "TASK_DECL", "entries.txt");
.el
.b
specifies that a full report is to be generated including all task declarations
in the dictionary and all declarations specified in the entry file
entries.txt.
.pg
The command
.b
.lt
    REPORT_DICTIONARY("[.mydict]", SUMMARY);
.el
.b
for a dictionary containing three unique object declarations and two
function declarations, one overloaded, would produce the following
summary report:
.b
.lt
Data Dictionary Report Output on 01/12/86 at 19:59:42                 1





OBJECT_DECL Entries:

    a

    Index_Table

    Index_Tree



FUNCTION_DECL Entries:

    afunction

    Second_Function
        takes string parameter
        takes string_type parameter

.el
.pg
The command
.b
.lt
    REPORT_DICTIONARY("[.mydict]", FULL, "FUNCTION_DECL afunction");
.el
.b
would produce the following full report:
.b
.lt
Data Dictionary Report Output on 01/13/86 at 15:32:10                 1





Function Declaration

function afunction                ( -- <overload>
    first_param : integer;          -- first parameter
    second_param : boolean;         -- second parameter
    <3.param>                       -- <3.comm>
    <4.param>                       -- <4.comm>
    ) return string;

-- Synonym: <syn>
-- 1/1/86                      Carol

-- This is an example function in the dictionary
-- This is line two in the description of this function
-- <3.desc>
-- <4.desc>
-- <5.desc>
-- <6.desc>
-- <7.desc>
-- <8.desc>
.el
.b
.hl1 How to Recover from Unexpected Situations
.p
This section describes what to do when something unexpected happens when
running one of the data dictionary tools.
.p
A user may not be able to open a data dictionary created with an older version
of the CREATE__DICTIONARY tool.
A dictionary created with an older version of CREATE__DICTIONARY
will be incompatible with a newer version of the tools
if
the new version of the tool involves any changes to the template forms.
To get a tool's
version number, run it without any parameters.  To get a dictionary's version
number, examine the contents of the file VERSION. in the dictionary.
.p
A user might not be able to access a dictionary because
of incorrect protections on the dictionary files.  All dictionary files
are created with the user's default protections at the time that
the CREATE__DICTIONARY command is run.
If a dictionary cannot be accessed because of incorrect protections, the
protections on the file can be changed appropriately.
The following is a list of the files in the dictionary directory and what
types of protections are necessary:
.b
.lt
    all files ending in ".INX" or ".DAT" - read and write permission
    VERSION.                             - read and write permission
    UNLOCKED.LCK                         - read permission
.el
.p
The dictionary might be left in a locked state due to
an untrappable interrupt, system crash, or some other reason.
If the dictionary is
locked, but nobody is really accessing it, it can be unlocked by
renaming the file in the dictionary called LOCKED.LCK to UNLOCKED.LCK.
This renaming should only be done in situations where it is absolutely
certain that nobody else is accessing the dictionary files.
.p
If the lock file is somehow accidentally deleted, it can be restored by
creating a file in the dictionary directory called UNLOCKED.LCK.
.hl1 System Peculiarities
.p
It is suggested that command line editing, as supported by VMS 4.0, be used
only with extreme caution.  VMS 4.0 supports command line editing with
control keys such as
CTRL/X, CTRL/H, CTRL/U, up arrow, etc.  While these will still work inside
the Edit__Dictionary editor, the screen display might not be accurately
updated.  For example, the prompt line might be overwritten while
using one of the VMS editing keys.
.hl1 Rehostability
.p
Host dependent subprograms are isolated in the packages Host__Lib and
File__Manager.  The bodies of these packages must be modified in order to
rehost the data dictionary tools.  In addition, the body for package
Terminal__IO may be modified to support additional terminal types (currently,
VT100 and VT52 compatible terminals are supported).  For additional information
on building the data dictionary tools, see Appendix B.
.ax Templates
.hl1 object declaration
.b
.lt
Object, Constant or Number Declaration

<ident>                       : -- <overload>
    <type>
        := <expr>

-- Synonym: <syn>
-- <date>                       <author>

-- <1.desc>
-- <2.desc>
-- <3.desc>
-- <4.desc>
-- <5.desc>
-- <6.desc>
-- <7.desc>
-- <8.desc>
-- <9.desc>
-- <10.desc>


.el
.pg
.hl1 type declaration
.b
.lt
Type Declaration

type <ident>                    is -- <overload>
    <1.def>
    <2.def>
    <3.def>
    <4.def>
    <5.def>
    <6.def>
    <7.def>
    <8.def>

-- Synonym: <syn>
-- <date>                       <author>

-- <1.desc>
-- <2.desc>
-- <3.desc>
-- <4.desc>
-- <5.desc>
.el
.pg
.hl1 procedure declaration
.b
.lt
Procedure Declaration

procedure <ident>                  ( -- <overload>
    <1.param>                        -- <1.comm>
    <2.param>                        -- <2.comm>
    <3.param>                        -- <3.comm>
    <4.param>                        -- <4.comm>
    );

-- Synonym: <syn>
-- <date>                       <author>

-- <1.desc>
-- <2.desc>
-- <3.desc>
-- <4.desc>
-- <5.desc>
-- <6.desc>
-- <7.desc>
-- <8.desc>
.el
.pg
.hl1 function declaration
.b
.lt
Function Declaration

function <ident>                   ( -- <overload>
    <1.param>                        -- <1.comm>
    <2.param>                        -- <2.comm>
    <3.param>                        -- <3.comm>
    <4.param>                        -- <4.comm>
    ) return <type>

-- Synonym: <syn>
-- <date>                       <author>

-- <1.desc>
-- <2.desc>
-- <3.desc>
-- <4.desc>
-- <5.desc>
-- <6.desc>
-- <7.desc>
-- <8.desc>
.el
.pg
.hl1 package declaration
.b
.lt
Package Declaration

package <ident>                 is -- <overload>
-- <comment>

-- Synonym: <syn>
-- <date>                       <author>

-- <1.desc>
-- <2.desc>
-- <3.desc>
-- <4.desc>
-- <5.desc>
-- <6.desc>
-- <7.desc>
-- <8.desc>
-- <9.desc>
-- <10.desc>

end;
.el
.pg
.hl1 task declaration
.lt
Task Declaration

task <ident>                    is -- <overload>
-- <comment>
    entry <1.decl>                 -- <1.comm>
    entry <2.decl>                 -- <2.comm>
    entry <3.decl>                 -- <3.comm>
    entry <4.decl>                 -- <4.comm>
end;

-- Synonym: <syn>
-- <date>                       <author>

-- <1.desc>
-- <2.desc>
-- <3.desc>
-- <4.desc>
-- <5.desc>
-- <6.desc>
-- <7.desc>
.el
.pg
.hl1 exception declaration
.b
.lt
Exception Declaration

<ident>                       : -- <overload>
    exception;

-- Synonym: <syn>
-- <date>                       <author>

-- <1.desc>
-- <2.desc>
-- <3.desc>
-- <4.desc>
-- <5.desc>
-- <6.desc>
-- <7.desc>
-- <8.desc>
-- <9.desc>
-- <10.desc>


.el
.ax Building the Data Dictionary Tools
.lt

To build the data dictionary tools:

 1. Compile all the abstractions into a program library (see READ.ME in
    abstractions directory for details).

 2. Compile everything named in the DATADICT.CO file into the program library
    containing the abstractions or a sublibrary whose parent library contains
    all the abstractions.  DATADICT.CO lists file names in the correct
    compilation order.

 3. Link Create_Dictionary_Driver, Edit_Dictionary_Driver,
    Update_Dictionary_Driver and Dictionary_Report_Driver with the program
    library where everything was compiled.  To do this using the DEC Ada
    compiler type:

    $ acs link create_dictionary_driver
    $ acs link edit_dictionary_driver
    $ acs link update_dictionary_driver
    $ acs link dictionary_report_driver

To run the tool on VMS:

 1. Define logical symbol for the executables of the data dictionary tools.
    For example,

    CREATE_DD :== $DRB1:[NOSC.TOOLS.DATADICT]CREATE_DICTIONARY_DRIVER.EXE
    EDIT_DD   :== $DRB1:[NOSC.TOOLS.DATADICT]EDIT_DICTIONARY_DRIVER.EXE
    UPDATE_DD :== $DRB1:[NOSC.TOOLS.DATADICT]UPDATE_DICTIONARY_DRIVER.EXE
    REPORT_DD :== $DRB1:[NOSC.TOOLS.DATADICT]DICTIONARY_REPORT_DRIVER.EXE

     NOTE: The full path name of the executable is required in the
     definition of the symbol.   The pathname given here is just an example
     and will be different on your system.

 2. Enter a command with appropriate parameters.  For example,

    CREATE_DD ("[.mydict]");

    Entering any of the commands with no parameters gives a brief
    description of how to use the tool.

Files contained in this directory:

DATADICT.CO  -- Compilation order for data dictionary sources
CDRIVER.EXE  -- VMS 4.0 Create_Dictionary executable
EDRIVER.EXE  -- VMS 4.0 Edit_Dictionary executable
UDRIVER.EXE  -- VMS 4.0 Update_Dictionary executable
RDRIVER.EXE  -- VMS 4.0 Dictionary_REPORT executable
DATADICT.CNT -- Ada source statement count
READ.ME      -- This file

The [.SOURCE] subdirectory contains most of the sources that make up the
data dictionary tools.  Other sources are contained in the abstractions
directory.

Files in [.SOURCE]:

    The source files which make up the data dictionary tools are as follows:

    RELEASE.BDY    -- Contains the version number of the data dictionary tools
    SSTRINGS.SPC   -- Screen Strings package (spec)
    TEMPLATES.SPC  -- All templates and operations on them (spec)
    DICTMGR.SPC    -- Subprograms to manipulate data dictionary
                      entries (spec)
    CDRIVER.ADA    -- Driver for Create_Dictionary tool
    SCREENMGR.SPC  -- Subprograms to manage placement of templates and data on
                      the screen (spec)
    COMMANDS.SPC   -- Subprograms to handle all editing commands for
                      Edit_Dictionary tool (spec)
    UPDATE.SPC     -- Subprograms to handle commands for Update_Dictionary
                      tool (spec)
    COMMANDS.BDY   -- Subprograms to handle all editing commands for
                      Edit_Dictionary tool (body)
    DICTMGR.BDY    -- Subprograms to manipulate data dictionary
                      entries (body)
    UPDATE.BDY     -- Subprograms to handle commands for Update_Dictionary
                      tool (body)
    EDRIVER.ADA    -- Driver for Edit_Dictionary tool
    RDRIVER.ADA    -- Driver for Dictionary_Report tool
    SCREENMGR.BDY  -- Subprograms to manage placement of templates and data on
                      the screen (body)
    SSTRINGS.BDY   -- Screen Strings package (body)
    TEMPLATES.BDY  -- All templates and operations on them (body)
    UDRIVER.ADA    -- Driver for Update_Dictionary tool

The [.TEST] subdirectory contains tests used in testing the data dictionary.
Since the Edit_Dictionary tool is interactive, most of the testing was done
interactively and not via test cases.

Files in [.TEST]:

    UPDATE.TST  -- Test various aspects of the Update_Dictionary tool.

The [.DOC] subdirectory contains the documentation for the data dictionary.

Files in [.DOC]:

    DATADICT.MEM -- Data Dictionary user's manual
    DATADICT.RNO -- Runoff input for Data Dictionary user's manual
    RELEASE.NTS  -- Release notes
.el