MULTICS TECHNICAL BULLETIN MTB-MRDS Model Manager
To: MTB Distribution
From: Charles Spitzer
Date: August 1, 1985
Subject: MRDS Model Manager
This document describes the interface to a software package that
manages the description of a MRDS database, otherwise known as
The Model. It also discusses the pros and cons of the current
model implementation and two alternative methods of storing the
data structures necessary to implement a MRDS model manager.
Discussion should take place in the System-M Forum meeting:
>udd>Demo>dbmt>con>MRDS_Development (mrdsdev)
or comments should be sent to the author:
via Multics Mail:
Spitzer@System-M
via US Mail:
Honeywell Information Systems, Inc.
PO Box 8000, MS T70
Phoenix, Arizona 85066
via telephone:
Charles Spitzer (602) 249-6677
_________________________________________________________________
Multics Project internal working documentation. Not to be
reproduced or distributed outside the Multics Project.
CONTENTS
Page
1: Introduction . . . . . . . . . . . . . . . . . 1
2: Current Implementation . . . . . . . . . . . . 1
2.1: Pros . . . . . . . . . . . . . . . . . . . . 2
2.2: Cons . . . . . . . . . . . . . . . . . . . . 3
3: Another Segment Implementation . . . . . . . . 3
3.1: Pros . . . . . . . . . . . . . . . . . . . . 4
3.2: Cons . . . . . . . . . . . . . . . . . . . . 4
4: Data Management Implementation . . . . . . . . 5
4.1: Pros . . . . . . . . . . . . . . . . . . . . 6
4.2: Cons . . . . . . . . . . . . . . . . . . . . 7
5: Conclusions . . . . . . . . . . . . . . . . . . 7
6: MRDS model manager subroutines . . . . . . . . 9
6.1: mrds_model_manager_$close_model . . . . . . . 9
6.2: mrds_model_manager_$copy_model . . . . . . . 10
6.3: mrds_model_manager_$create_attribute . . . . 11
6.4: mrds_model_manager_$create_domain . . . . . . 13
6.5: mrds_model_manager_$create_index . . . . . . 15
6.6: mrds_model_manager_$create_model . . . . . . 17
6.7: mrds_model_manager_$create_relation . . . . . 19
6.8: mrds_model_manager_$create_relation_link . . 21
6.9: mrds_model_manager_$delete_attribute . . . . 23
6.10: mrds_model_manager_$delete_domain . . . . . . 25
6.11: mrds_model_manager_$delete_index . . . . . . 27
6.12: mrds_model_manager_$delete_model . . . . . . 29
6.13: mrds_model_manager_$delete_relation . . . . . 30
6.14: mrds_model_manager_$get_attribute_info . . . 31
6.15: mrds_model_manager_$get_attribute_list . . . 33
6.16: mrds_model_manager_$get_attribute_xref . . . 35
6.17: mrds_model_manager_$get_db_info . . . . . . . 37
6.18: mrds_model_manager_$get_domain_info . . . . . 38
6.19: mrds_model_manager_$get_domain_list . . . . . 40
6.20: mrds_model_manager_$get_domain_xref . . . . . 42
6.21: mrds_model_manager_$get_history . . . . . . . 44
6.22: mrds_model_manager_$get_index_info . . . . . 45
6.23: mrds_model_manager_$get_relation_info . . . . 48
6.24: mrds_model_manager_$get_relation_list . . . . 50
6.25: mrds_model_manager_$initialize_model . . . . 52
6.26: mrds_model_manager_$modify_attribute . . . . 53
6.27: mrds_model_manager_$modify_domain . . . . . . 55
6.28: mrds_model_manager_$modify_relation . . . . . 58
6.29: mrds_model_manager_$open_model . . . . . . . 61
CONTENTS (cont)
Page
6.30: mrds_model_manager_$quiesce_model . . . . . . 62
6.31: mrds_model_manager_$secure_database . . . . . 63
6.32: mrds_model_manager_$set_db_info . . . . . . . 64
6.33: mrds_model_manager_$set_restructure_history . 66
6.34: mrds_model_manager_$unquiesce_model . . . . . 67
6.35: mrds_model_manager_$unsecure_database . . . . 68
Appendix A: DM File Record Definitions . . . . . . 69
A.1: mmm_attribute_record.incl.pl1 . . . . . . . . 69
A.2: mmm_attribute_xref_rec.incl.pl1 . . . . . . . 70
A.3: mmm_db_record.incl.pl1 . . . . . . . . . . . 71
A.4: mmm_domain_record.incl.pl1 . . . . . . . . . 73
A.5: mmm_domain_xref_record.incl.pl1 . . . . . . . 75
A.6: mmm_history_info.incl.pl1 . . . . . . . . . . 76
A.7: mmm_relation_record.incl.pl1 . . . . . . . . 78
Appendix B: Supported Data Types . . . . . . . . . 81
MTB-717 MTB-MRDS Model Manager
1: INTRODUCTION
A MRDS database may be created through the use of the
create_mrds_db command or the restructure_mrds_db subsystem. In
both cases, certain elements of information must be specified by
the Data Base Administrator (DBA) that describe the MRDS
database. The complete set of database description information
is known as the database data model.
This document describes the interface between MRDS and a software
subsystem named mrds_model_manager_. The contract of the
mrds_model_manager_ is to maintain the MRDS data model
consistently and independently from the rest of the MRDS
subsystem. This allows us to change the implementation method or
the contents of the MRDS model without requiring modifications to
the mrds_model_manager_ subroutine interface or to MRDS itself.
The current implementation and two other implementations are
discussed in the next section, with points of comparison between
the implementations being:
o* security of accessing elements of the model
o* speed of accessing elements of the model
o* how easy is to modify the model
o* consistency of the model and the data relations taking into
account interruptions of model modification operations
o* runtime execution implications
o* support for existing models.
2: CURRENT IMPLEMENTATION
The data model is currently implemented as a set of segments; a
single segment named db_model, and a number of segments, one per
relation, named <relation_name>.m. All of these segments are
read and written by initiating the segment and overlaying a
structure on the segment. Each of them contain a header at the
beginning of the segment, followed by a freeing, nonextensible
area. The header specifies offsets of where one or more linked
lists begin; the linked lists are allocated within the area.
Some of the information structures contain offsets into other
model segments; pointers to these other structures are created
using a pointer to the head of the segment and the offset stored.
The db_model segment contains, among other elements, a linked
list of relations and a linked list of all defined domains in the
database. It also contains other various structures, including
MTB-MRDS Model Manager MTB-717
information about the last process that performed restructuring
operations upon the database, the database version, and a text
message that contains a printable message to be displayed when a
user attempts to open the database while it is being
restructured.
The relation.m segments contain information specific to a single
relation. Of the collection of elements that are actually used
in the current MRDS implementation, the major part is a linked
list of all attributes used within the relation. Each of these
attribute structures contains offsets into the db_model segment
to indicate the underlying domain of the attribute. Other
information kept in the file model is the knowledge of the
primary and any secondary indices for the relation, number of
varying attributes in each tuple and the bit offset of the start
of the first varying attribute.
There are two other segments that may be thought of as part of
the database model. These two segments are named dbcb and rdbi,
and reside in the directory resultant_segs.dir under the database
directory. These segments contain parts of the database model
that have been copied out of the rest of the database model
segments (db_model and file models) and other data elements that
are used only during the runtime portion of the MRDS subsystem.
If the user process has been given read access to these segments,
they are copied verbatum from the database directory into the
process's temporary space directory, typically the process
directory. Then the runtime elements of the two segments are
initialized. If the process has not been given access to the
dbcb and the rdbi, these two segments are created and completely
initialized as part of the MRDS open operation. They are used
only to allow a database open operation to be completed faster
than if each process had to retrieve all the necessary
information from the model each time the database was opened.
2.1: Pros
Some reasons for implementing the model this way are:
o* Accessing the various data structures in the model may be done
by simply using a pointer to the base of the segment and using
pointer I/O to read in the segment. This means that model
accesses may be accomplished easily and fast.
o* Access to some of the model information may be controlled using
normal segment ACLs, that being an ACL on the relation file
model segment.
o* There is some similarity between the structures containing the
model information and the structures that are used during MRDS
MTB-717 MTB-MRDS Model Manager
execution. This implies that model structures may be copied
verbatum into the runtime structures.
2.2: Cons
Some reasons against implementing the model this way are:
o* Since these segments are used as structures, it becomes hard,
if not impossible, to extend or remove obsolete information
without some type of conversion tool that must be run over all
MRDS databases on a system. It also makes it hard to run
different versions of MRDS upon the same system.
o* There are no checks within the model for consistency. Because
of this, any type of process or system interruption while the
data model is being restructured brings up the possibility that
the model may become inconsistent and the MRDS database become
unusable.
o* As a restructuring delete operation causes data to be lost from
the model, it thus becomes impossible to rollback operations
that impact the model.
o* Since there is no concept of unreferenced domains or
attributes, there is no means to a lot of the more commonly
needed operations of restructuring, like creating domains or
attributes for later use in relations. Also, since the
relation segments are the only place information about
attributes is kept, when a relation is deleted and an attribute
is contained within that relation, all information about that
attribute is also deleted. Thus one cannot use that attribute
within another newly created relation.
o* Not all information about a specific relation is kept within
the file model segment, thus a DBA cannot restrict access to
all model information using only ACLs on the file model
segment. Users may still obtain information about the database
model that they may not have a need to see.
o* Searching for an entry in any of the linked lists is of order
O(n^2) as the lists are not kept in any type of sorted order.
3: ANOTHER SEGMENT IMPLEMENTATION
The current implementation has various structures allocated in
non-extensible non-freeing areas based in permanent segments that
make up the MRDS model. Some of the structures are allocated in
more than a single place, and the structures are managed as
unsorted forward threaded linked lists. A more efficient way to
keep these structures would be to have them stored in three
MTB-MRDS Model Manager MTB-717
segments: a) a segment for information concerning the database
header and the list of relations, b) a list of all attributes
defined within the database, and c) a list of all domains defined
within the database.
The two segments that contain only lists may then be accessed as
fixed length arrays, since in order to add new entries or to
delete entries the array bounds may simply be adjusted. If the
entries are kept in sorted order, then they may be accessed using
a binary search rather than searching the entire list to find an
appropriate entry. The list of relations may contain a list of
indices into the attribute list for the attributes which comprise
the relation, and the attribute entry may contain the index into
the domain list for the underlying domain.
3.1: Pros
Some reasons for implementing the model this way are:
o* Accessing the various data structures in the model may be done
by simply using a pointer to the base of the segment and using
pointer I/O to read in the segment. This means that model
accesses may be accomplished easily and fast.
o* There is some similarity between the structures containing the
model information and the structures that are used during MRDS
execution. This implies that model structures may be copied
verbatum into the runtime structures.
o* The structures are not duplicated anywhere, and may be more
easily and quickly searched using array indices and a binary
search method rather than searching linked lists.
o* The various runtime resultant segments need not be modified.
o* If each of the database model segments is given a version
number, a modification to any part of the model structures need
not obsolete all of the model by causing a new version of
database to be implemented. For example, the subroutines that
deal with attributes could support multiple versions of the
attribute segment without the rest of the MRDS code being
modified to support new version databases.
3.2: Cons
Some reasons against implementing the model this way are:
o* Since these segments are used as structures, it becomes hard,
if not impossible, to extend or remove obsolete information
without some type of conversion tool that must be run over all
MTB-717 MTB-MRDS Model Manager
MRDS databases on a system. It also makes it hard to run
different versions of MRDS upon the same system.
o* There are no checks within the model for consistency. Because
of this, any type of process or system interruption while the
data model is being restructured brings up the possibility that
the model may become inconsistent and the MRDS database become
unusable.
o* As a restructuring delete operation causes data to be lost from
the model, it thus becomes impossible to rollback operations
that impact the model.
o* Because information pertaining to relations, attributes and
domains is kept within three segments, it becomes hard to
control access to model information without ACL records in the
model or SQL-type access statements in the model language.
4: DATA MANAGEMENT IMPLEMENTATION
Another implementation method would be to implement the MRDS
model as a DM keyed file, with each record within the model
containing a description of a piece of the model. Different
types of records would be implemented, each defining a seperate
piece of the model. In MRDS relation notation, a record would be
described as:
relation: record (record_type* name* data);
where the record_type (char (32)) field defines the type of the
record, the name (char (32) indicates what this record defines,
and the data (bit (sys_info$max_seg_size*36) varying) may be
overlayed with a structure, and defines any additional data for
this type of record.
The types of records initially defined, but not limited to this
list, would be:
ATTRIBUTE
which defines a single attribute, whether it is referenced
or unreferenced. The record contains information about the
underlying domain of the attribute.
DOMAIN
which defines a single domain, whether it is referenced or
unreferenced. The record contains information about the
underlying data type, and any defined special procedures.
RELATION
which defines a single relation. The record contains
information about the relation, a list of attributes
MTB-MRDS Model Manager MTB-717
contained within the relation, and information concerning
the primary and any defined secondary indices for the
relation.
DATABASE
which defines the database. The record contains information
about the database, quiesced state, what type of
transactions to use when operating upon this database,
database versions, and history concerning when the database
was created or restructured.
DOMAIN_XREF
which define a domain cross reference. The record contains
a list of attributes which use this specific domain. These
records are only used for restructuring.
ATTRIBUTE_XREF
which define an attribute cross reference. The record
contains a list of relations which use this specific
attribute. These records are only used for restructuring.
Each record in the model DM file will contain a version string
that is stored within the data portion of the record.
The permanent resultant segments and the resultant_segs.dir
directory shall be deleted. These segments are used only during
runtime, and as such shall be created, built, and deleted as
parts of the dsl_ subsystem are executed. Since these segments
contain various data from the model, they will be built
incrementally; that is they will contain the information for
relations, attributes, and domains that have been used within a
selection expression, and will not contain information about
elements of the model that have not been used during the MRDS
execution.
4.1: Pros
Some reasons for implementing the model this way are:
o* The DBA can create and/or modify the model and be able to
rollback the changes due to using the model under a
transaction. Also, this solves the problem in the current MRDS
that a system or process failure may cause an inconsistency
between the model and data relations if the model was being
restructured.
o* Each record in the model has a version so changing a single
record type does not impact the rest of the model. The tool to
change record versions need only modify a single set of records
within the model.
MTB-717 MTB-MRDS Model Manager
o* The model is easily extensible, simply by adding new record
types to the relation and overlaying new structures upon the
data field of the record.
o* Since it is only in the worst case that an application needs a
complete definition of the MRDS model, the incremental runtime
structure building process implies that typical applications
need not skip over model information that is not used within
the application. This saves space in the various runtime
structures and processing time skipping information.
o* Using a data management file for the MRDS model will probably
use less quota than the current model implementation for medium
to large databases, in that model description information does
not need to be duplicated.
4.2: Cons
Some reasons against implementing the model this way are:
o* Because all of the MRDS model information is kept within a
single data management file, it becomes hard to control access
to model information without ACL records in the model or
SQL-type access statements in the model language.
o* Having all accesses to the MRDS model be accomplished using
data management routines will mean that the speed to access the
appropriate information will be slower than currently
implemented. However, since information will be kept in the
runtime structures there need only be one reference to the
model itself; thus in the long run it may prove to be faster.
o* Implementing the MRDS model as a data management file implies
that a running DM system is mandatory to execute any MRDS
programs.
o* A tool must be written to convert all existing MRDS database
models to the next version models.
5: CONCLUSIONS
The points mentioned against using DM files are of minor
consequence and do not override the importance of the points for
using DM files to implement the model.
o* The current implementation only hides the fact if which
attributes are used within a specific relation, as all other
information is in a user accessible segment. Having the entire
model be readable by any user that has access to the MRDS
database does not give away any priviledged information, and
MTB-MRDS Model Manager MTB-717
submodels should be used in the cases where the data should be
hidden.
o* We cannot tell if implementing the MRDS model manager using DM
files is to be slower or not without proceeding with the
implementation.
o* As more and more of the operating system will be using DM
files, it will become a requirement that DM be already running.
Users are migrating to using DM files for their data for
concurrancy, so this requirement becomes of less importance.
o* Updating to the next version of database model is a minor
problem at best. It could easily be run against the system
hiearchy during the process of installing the new release, or
run against an individual database by the DBA.
Since data integrity, and integrity between the data relations
and the MRDS model description is of paramount importance, the
method described in section 4 (Data Management Implementation)
shall be implemented for the next release of the MRDS product
during the post-MR11 timeframe.
MTB-717 MTB-MRDS Model Manager
6: MRDS MODEL MANAGER SUBROUTINES
The following sections describe the subroutine interface to the
mrds_model_manager_ entries.
6.1: mrds_model_manager_$close_model
Name: mrds_model_manager_$close_model
This procedure removes the indicated database data model from the
table of known data models.
Usage:
declare mrds_model_manager_$close_model entry
(fixed bin (35), char (*), fixed bin (35));
call mrds_model_manager_$close_model
(data_model_index, error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
3. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
MTB-MRDS Model Manager MTB-717
6.2: mrds_model_manager_$copy_model
Name: mrds_model_manager_$copy_model
This procedure copies the data model from one place in the
Multics file system to another.
Usage:
declare mrds_model_manager_$copy_model entry
(ptr, char (*), fixed bin (35));
call mrds_model_manager_$copy_model
(copy_options_ptr, error_message, code);
Arguments:
1. copy_options_ptr (Input) (ptr)
is a pointer to the structure declared in
copy_options.incl.pl1.
2. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
3. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
MTB-717 MTB-MRDS Model Manager
6.3: mrds_model_manager_$create_attribute
Name: mrds_model_manager_$create_attribute
This procedure creates one or more unreferenced attributes in the
indicated database data model.
Usage:
declare mrds_model_manager_$create_attribute entry
(fixed bin (35), ptr, char (*), fixed bin (35));
call mrds_model_manager_$create_attribute
(data_model_index, create_attribute_request_ptr,
error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. create_attribute_request_ptr (Input) (ptr)
is a pointer to the structure declared in
mmm_create_attribute_rq.incl.pl1, which defines the
attributes that are to be created.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The create_attribute_request structure is defined as:
dcl 1 create_attribute_request aligned based (car_ptr),
2 version char (8) unaligned,
2 count fixed bin (17),
2 attribute (create_attribute_request_count refer
(create_attribute_request.count)),
3 attribute_name char (32) unaligned,
3 domain_name char (32) unaligned;
where:
0. version
is set to CREATE_ATTRIBUTE_VERSION_1.
MTB-MRDS Model Manager MTB-717
1. count
is the number of attributes to be created.
2. attribute_name
is the name of the unreferenced attribute to create.
3. domain_name
is the name of the underlying domain. All of the specified
domains must exist within the indicated data model.
MTB-717 MTB-MRDS Model Manager
6.4: mrds_model_manager_$create_domain
Name: mrds_model_manager_$create_domain
This procedure creates one or more unreferenced domain in the
indicated database data model.
Usage:
declare mrds_model_manager_$create_domain entry
(fixed bin (35), ptr, char (*), fixed bin (35));
call mrds_model_manager_$create_domain
(data_base_index, create_domain_request_ptr,
error_message, code);
Arguments:
1. data_base_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. create_domain_request_ptr (Input) (ptr)
is a pointer to the structure declared in
mmm_create_domain_rq.incl.pl1, which defines the domain that
is to be created.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The create_domain_request structure is defined as:
dcl 1 create_domain_request aligned based (cdr_ptr),
2 version char (8) unaligned,
2 count fixed bin (17),
2 domain (create_domain_request_count refer
(create_domain_request.count)),
3 domain_name char (32) unaligned,
3 domain_descriptor bit (36),
3 decode_declare_data_descriptor bit (36),
3 check_procedure_path char (168) unaligned,
3 decode_procedure_path char (168) unaligned,
3 encode_procedure_path char (168) unaligned;
where:
MTB-MRDS Model Manager MTB-717
0. version
is set to CREATE_DOMAIN_VERSION_1.
1. domain_name
is the name of the unreferenced domain to be created.
2. count
is the number of domains to create.
3. domain_descriptor
is the underlying data type, described as a standard Multics
descriptor. See Appendix B for a list of supported data
types.
4. decode_declare_data_descriptor
is the data type to be used for the user's view and the
decode procedure, if present. If this field is not used, it
must be set to "0"b. See Appendix B for a list of supported
data types.
5. check_procedure_path
is an absolute pathname pointing to the procedure to be
called to perform data verification checks upon storage into
the database. If this field is not to be used, it must be
set to "".
6. decode_procedure_path
is an absolute pathname pointing to the procedure to be
called to perform data decoding upon retrieval from the
database. If this field is not to be used, it must be set
to "".
7. encode_procedure_path
is an absolute pathname pointing to the procedure to be
called to perform data encoding before storage into an
internal database form. If this field is not to be used, it
must be set to "".
MTB-717 MTB-MRDS Model Manager
6.5: mrds_model_manager_$create_index
Name: mrds_model_manager_$create_index
This procedure creates an index in the database data model for
the indicated relation.
Usage:
declare mrds_model_manager_$create_index entry
(fixed bin (35), ptr, bit (36) aligned,
char (*), fixed bin (35));
call mrds_model_manager_$create_index
(data_model_index, create_index_request_ptr,
index_id, error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. create_index_request_ptr (Input) (ptr)
is a pointer to the structure declared in
mmm_create_index_rq.incl.pl1, which defines the index that
is to be created.
3. index_id (Output) (bit (36) aligned)
is the index identifier of the created index to the
relation.
4. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
5. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The create_index_request is defined as:
dcl 1 create_index_request aligned based (cri_ptr),
2 version char (8) unaligned,
2 relation_name char (32) unaligned,
2 index_name char (32) unaligned,
2 count fixed bin (17),
2 flags unaligned,
3 unique bit (1),
3 pad bit (35),
2 attribute_name (create_index_request_count refer
MTB-MRDS Model Manager MTB-717
(create_index_request.count))
char (32) unaligned;
where:
0. version
is set to CREATE_INDEX_VERSION_1.
1. relation_name
is the name of the relation to create the index within.
2. index_name
is the name of the index to be created. Index names must be
unique within a single relation.
3. count
is the number of attributes that are to make up the index.
4. flags.unique
if set, indicates that the data contained in the set of
attributes for the index must be unique.
5. attribute_name
is the name of the attribute to be part of the index. The
index consists of the set of attributes and is created in
the order that the attributes are specified in.
MTB-717 MTB-MRDS Model Manager
6.6: mrds_model_manager_$create_model
Name: mrds_model_manager_$create_model
This procedure creates the proper database data model entries in
the Multics file system, and initializes them to indicate that
there are no domains, attributes or relations.
Usage:
declare mrds_model_manager_$create_model entry
(ptr, char (*), fixed bin (35));
call mrds_model_manager_$create_model
(create_model_request_ptr, error_message, code);
Arguments:
1. create_model_request_ptr (Input) (ptr)
is a pointer to the structure declared in
mmm_create_model_rq.incl.pl1, which defines the model that
is to be created.
2. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
3. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The create_model_request structure is defined as:
dcl 1 create_model_request aligned
based (create_model_request_ptr),
2 version char (8) unaligned,
2 db_directory_name char (168) unaligned,
2 db_entry_name char (32) unaligned,
2 default_relation_type fixed bin (17) unaligned,
2 flags unaligned,
3 before_journalizing bit (1),
3 concurrency bit (1),
3 pad bit (16),
2 command_name char (32) unaligned,
2 command_version char (8) unaligned;
where:
0. version
is set to CREATE_MODEL_VERSION_1.
MTB-MRDS Model Manager MTB-717
1. db_directory_name
is the directory portion of the MRDS database pathname.
2. db_entry_name
is the entry portion of the MRDS database pathname, with or
without the database suffix.
3. default_relation_type
specifies the type of relation to create by default if the
type is not specified at relation creation time. The only
types supported are VFILE_TYPE and DMFILE_TYPE, defined in
mmm_file_types.incl.pl1.
4. flags.before_journalizing
if set, implies that before journals are to be taken for the
DM files in this database.
5. flags.concurrency
if set, implies that DM file concurrency is to be used.
6. command_name
is the name of the command or subsystem making the request
to create the model. This is stored within the
create_history of the model.
7. command_version
is the version of the command or subsystem named in the
command_name field.
MTB-717 MTB-MRDS Model Manager
6.7: mrds_model_manager_$create_relation
Name: mrds_model_manager_$create_relation
This procedure creates a relation in the indicated database data
model. All referenced domains and attributes must exist prior to
use of this entry point.
Usage:
declare mrds_model_manager_$create_relation entry
(fixed bin (35), ptr, char (*), fixed bin (35));
call mrds_model_manager_$create_relation
(data_model_index, create_relation_request_ptr,
error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. create_relation_request_ptr (Input) (ptr)
is a pointer to the structure declared in
mmm_create_relation_rq.incl.pl1, which defines the relation
that is to be created.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The create_relation_request structure is defined as:
dcl 1 create_relation_request aligned based (crr_ptr),
2 version char (8) unaligned,
2 relation_name char (32) unaligned,
2 count fixed bin (17),
2 type fixed bin (17),
2 flags unaligned,
3 type_specified bit (1),
3 pad bit (35),
2 attribute_name (create_relation_request_count refer
(create_relation_request.count))
char (32) unaligned;
where:
MTB-MRDS Model Manager MTB-717
0. version
is set to CREATE_RELATION_VERSION_1.
1. relation_name
is the name of the relation to create.
2. count
is the number of attributes that are to comprise the
attribute set in the relation to be created.
3. type
is the type of relation to create. The only supported types
are VFILE_TYPE and DMFILE_TYPE, defined in
mmm_relation_types.incl.pl1.
4. flags.type_specified
if set, indicates that the type field has been specified.
Otherwise, the type of the relation to be created shall be
the default relation type as specified when the model was
created.
5. attribute_name
is the name of the attribute to be included in the relation.
All of the specified attributes must exist within the data
model. The relation is created from the set of attributes
in the order in which they are specified.
MTB-717 MTB-MRDS Model Manager
6.8: mrds_model_manager_$create_relation_link
Name: mrds_model_manager_$create_relation_link
This procedure creates a link relation in the specified database
data model. The target of the link relation is contained within
another separate MRDS database, and may or may not exist. The
target relation must exist when the link relation is used within
an application (eg., within a select expression). The DBA need
not have any access to the target of the link relation.
Usage:
declare mrds_model_manager_$create_relation_link entry
(fixed bin (35), ptr, char (*), fixed bin (35));
call mrds_model_manager_$create_relation_link
(data_model_index, create_relation_link_request_ptr,
error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. create_relation_link_request_ptr (Input) (ptr)
is a pointer to the structure declared in
mmm_create_rel_link_rq.incl.pl1, which defines the relation
that is to be created.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The create_relation_link_request structure is defined as:
dcl 1 create_relation_link_request aligned based (crl_ptr),
2 version char (8) unaligned,
2 relation_name char (32) unaligned,
2 foreign_database_path char (168) unaligned,
2 foreign_database_relation_name char (32) unaligned;
where:
0. version
is set to CREATE_RELATION_LINK_VERSION_1.
MTB-MRDS Model Manager MTB-717
1. relation_name
is the name of the link relation in the database specified
by the data_model_index.
2. foreign_database_path
is an absolute pathname to the database that contains the
specified foreign relation with the database suffix. The
DBA need not have access to the foreign database and the
foreign relation need not exist. However, in these cases,
the link relation shall be created and the non-fatal error
code mrds_error_$link_not_found will be returned.
3. foreign_database_relation_name
is the name of the target relation in the foreign database.
MTB-717 MTB-MRDS Model Manager
6.9: mrds_model_manager_$delete_attribute
Name: mrds_model_manager_$delete_attribute
This procedure deletes one or more referenced or unreferenced
attributes from the data model. If an attribute is referenced in
one or more relations, the referenced relations are reformatted
so as to not contain the indicated attributes.
Usage:
declare mrds_model_manager_$delete_attribute entry
(fixed bin (35), ptr, char (*), fixed bin (35));
call mrds_model_manager_$delete_attribute
(data_model_index, delete_attribute_request_ptr,
error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. delete_attribute_request_ptr (Input) (ptr)
is a pointer to the structure declared in
mmm_delete_attribute_rq.incl.pl1, which defines the set of
attributes that are to be deleted.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The delete_attribute_request structure is defined as:
dcl 1 delete_attribute_request aligned based (dar_ptr),
2 version char (8) unaligned,
2 flags unaligned,
3 all bit (1),
3 unreferenced bit (1),
3 reserved bit (34),
2 count fixed bin (17),
2 attribute_name (delete_attribute_request_count refer
(delete_attribute_request.count))
char (32) unaligned;
where:
MTB-MRDS Model Manager MTB-717
0. version
is set to DELETE_ATTRIBUTE_VERSION_1.
1. flags.all
is set to "1"b if all referenced and unreferenced attributes
are to be deleted. The attribute count must be set to zero
if this flag is on.
2. flags.unreferenced
is set to "1"b if all unreferenced attributes are to be
deleted. The attribute count must be set to zero if this
flag is on.
3. count
if both flags.all and flags.unreferenced are off, this field
is used to indicate the number of attributes to be deleted
from the data model.
4. attribute_name
is the name of the attribute to be deleted.
Notes: If any of the specified attributes are referenced, the
relation containing them will be reformatted. This also causes
any indices containing this attribute to be deleted.
MTB-717 MTB-MRDS Model Manager
6.10: mrds_model_manager_$delete_domain
Name: mrds_model_manager_$delete_domain
This procedure deletes one or more referenced or unreferenced
domains from the data model. If a domain is referenced by one or
more attributes, the indicated attributes are deleted, causing
the referenced relations to be reformatted so as to not contain
the referenced attributes.
Usage:
declare mrds_model_manager_$delete_domain entry
(fixed bin (35), ptr, char (*), fixed bin (35));
call mrds_model_manager_$delete_domain
(data_model_index, delete_domain_request_ptr,
error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. delete_domain_request_ptr (Input) (ptr)
is a pointer to the structure declared in
mmm_delete_domain_rq.incl.pl1, which defines the set of
domains that are to be deleted.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The delete_domain_request structure is defined as:
dcl 1 delete_domain_request aligned based (ddr_ptr),
2 version char (8) unaligned,
2 flags unaligned,
3 all bit (1),
3 unreferenced bit (1),
3 reserved bit (34),
2 count fixed bin (17),
2 domain_name (delete_domain_request_count refer
(delete_domain_request.count))
char (32) unaligned;
where:
MTB-MRDS Model Manager MTB-717
0. version
is set to DELETE_DOMAIN_VERSION_1.
1. flags.all
is set to "1"b if all referenced and unreferenced domains
are to be deleted. The domain count must be set to zero if
this flag is on.
2. flags.unreferenced
is set to "1"b if all unreferenced domains are to be
deleted. The domain count must be set to zero if this flag
is on.
3. count
if both flags.all and flags.unreferenced are off, this field
is used to indicate the number of domains to be deleted from
the data model.
4. domain_name
is the name of the domain to be deleted. If any of the
specified domains are referenced, the attribute defined upon
them shall be deleted from the data model and the relations
containing them will be reformatted.
MTB-717 MTB-MRDS Model Manager
6.11: mrds_model_manager_$delete_index
Name: mrds_model_manager_$delete_index
This procedure deletes one or more indices from the specified
relation.
Usage:
declare mrds_model_manager_$delete_index entry
(fixed bin (35), ptr, char (*), fixed bin (35));
call mrds_model_manager_$delete_index
(data_model_index, delete_index_request_ptr,
error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. delete_index_request_ptr (Input) (ptr)
is a pointer to the structure declared in
mmm_delete_index_rq.incl.pl1, which defines the set of
indices that are to be deleted.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The delete_index_request structure is defined as:
dcl 1 delete_index_request aligned based (dir_ptr),
2 version char (8) unaligned,
2 relation_name char (32) unaligned,
2 count fixed bin (17),
2 index (delete_index_request_count refer
(delete_index_request.count)),
3 name char (32) unaligned,
3 id bit (36) aligned;
0. version
is set to DELETE_INDEX_VERSION_1;
1. relation_name
is the name of the relation to delete the indices from.
MTB-MRDS Model Manager MTB-717
2. count
is the number of indices to be deleted.
3. index.name
if set, specifies the name of the index to delete. If this
field is not used, it must be set to all blanks.
4. index.id
if set, specifies the index id returned by
mrds_model_manager_$create_index of the index to delete. If
this field is not used, it must be set to zero ("0"b).
Notes:
One of the fields, index.id or index.name, must be specified in
order to delete an index; otherwise an error is returned.
MTB-717 MTB-MRDS Model Manager
6.12: mrds_model_manager_$delete_model
Name: mrds_model_manager_$delete_model
This procedure deletes the database data model entries from the
Multics file system.
Usage:
declare mrds_model_manager_$delete_model entry
(char (*), char (*), char (*), fixed bin (35));
call mrds_model_manager_$delete_model
(db_directory_name, db_entry_name, error_message, code);
Arguments:
1. db_directory_name (Input) (char (*))
is the directory portion of the MRDS database pathname.
2. db_entry_name (Input) (char (*)
is the entry portion of the MRDS database pathname, with or
without the database suffix.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
MTB-MRDS Model Manager MTB-717
6.13: mrds_model_manager_$delete_relation
Name: mrds_model_manager_$delete_relation
This procedure deletes a relation from the MRDS data model.
Usage:
declare mrds_model_manager_$delete_relation entry
(fixed bin (35), char (*), char (*),
fixed bin (35));
call mrds_model_manager_$delete_relation
(data_model_index, relation_name, error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. relation_name (Input) (char (*))
is the name of the relation to be deleted.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
MTB-717 MTB-MRDS Model Manager
6.14: mrds_model_manager_$get_attribute_info
Name: mrds_model_manager_$get_attribute_info
This procedure returns information stored in the MRDS data model
about a single attribute.
Usage:
declare mrds_model_manager_$get_attribute_info entry
(fixed bin (35), ptr, char (*), fixed bin (35));
call mrds_model_manager_$get_attribute_info
(data_model_index, attribute_info_ptr, error_message,
code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. attribute_info_ptr (Input) (ptr)
is a pointer to the structure declared in
mmm_attribute_info.incl.pl1, which defines the information
to be returned about the specified attribute. If this field
is null, no attribute information is returned; however the
existence of the attribute is still verified. The version
field must be set to indicate which version of information
to return.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The attribute_info structure is defined as:
dcl 1 attribute_info aligned based (attribute_info_ptr),
2 version char (8) unaligned,
2 attribute_name char (32) unaligned,
2 domain_name char (32) unaligned,
2 reference_count fixed bin (17),
2 creation_history like history_info,
2 change_history like history_info;
where:
MTB-MRDS Model Manager MTB-717
0. version
is set to ATTRIBUTE_INFO_VERSION_1.
1. attribute_name
is the name of the attribute information is to be returned.
2. domain_name
is the name of the underlying domain.
3. reference_count
is the number of relations this attribute is referenced in.
4. creation_history
specifies information about the process that had created the
attribute.
5. change_history
specifies information about the process that has last
modified the attribute.
MTB-717 MTB-MRDS Model Manager
6.15: mrds_model_manager_$get_attribute_list
Name: mrds_model_manager_$get_attribute_list
This procedure returns the number of attributes defined within
the specified MRDS model, and optionally the list of names of all
attributes defined.
Usage:
declare mrds_model_manager_$get_attribute_list entry
(fixed bin (35), char (8), ptr, fixed bin (17),
ptr, char (*), fixed bin (35));
call mrds_model_manager_$get_attribute_list
(data_model_index, name_list_version, user_area_ptr,
name_list_count, name_list_ptr, error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. name_list_version (Input) (char (8))
specifies which version of name_list structure to allocate.
3. user_area_ptr (Input) (ptr)
is a pointer to the area to create the name_list structure
within. If this field is null, no name_list structure is
allocated; however the number of defined attributes is still
returned.
4. name_list_count (Output) (fixed bin (17))
is the number of attributes defined in the
name_list_structure.
5. name_list_ptr (Output) (ptr)
is a pointer to the structure declared in
mmm_name_list.incl.pl1, which defines the list of attribute
names to be returned.
6. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
7. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The name_list structure is defined as:
MTB-MRDS Model Manager MTB-717
dcl 1 name_list aligned based (name_list_ptr),
2 version char (8) unaligned,
2 count fixed bin (17),
2 name (name_list_count refer (name_list.count))
char (32) unaligned;
where:
0. version
is set to NAME_LIST_VERSION_1.
1. count
is the total number of attributes defined within the MRDS
model.
2. name
is the name of the attribute.
MTB-717 MTB-MRDS Model Manager
6.16: mrds_model_manager_$get_attribute_xref
Name: mrds_model_manager_$get_attribute_xref
This procedure returns a list of relations in which the specified
attribute is referenced, or an indication that it is
unreferenced.
Usage:
declare mrds_model_manager_$get_attribute_xref entry
(fixed bin (35), char (*), char (8), ptr,
ptr, fixed bin (17), char (*), fixed bin (35));
call mrds_model_manager_$get_attribute_xref
(data_model_index, attribute_name,
crossreference_info_version, user_area_ptr,
crossreference_info_ptr, reference_count,
error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. attribute_name (Input) (char (*))
is the name of the attribute about which the relation
crossreference is to be returned.
3. crossreference_version (Input) (char (8))
specifies which version of crossreference_info structure to
allocate.
4. user_area_ptr (Input) (ptr)
is a pointer to the area to create the crossreference_info
structure within. If this field is null, no
crossreference_info structure is allocated; however the
number of relations this attribute is referenced within is
still returned or an error code is returned if the attribute
does not exist.
5. crossreference_info_ptr (Output) (ptr)
is a pointer to the structure declared in
mmm_crossreference_info.incl.pl1, which defines the relation
crossreference to be returned about the specified attribute.
If user_area_ptr is null, this field will be set to null.
6. reference_count (Output) (fixed bin (17))
is the number of relations the specified attribute is
referenced in.
MTB-MRDS Model Manager MTB-717
7. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
8. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The crossreference_info structure is defined as:
dcl 1 crossreference_info aligned based
(crossreference_info_ptr),
2 version char (8) unaligned,
2 parent char (32) unaligned,
2 reference_count fixed bin (17),
2 child (crossreference_info_reference_count refer
(crossreference_info.reference_count))
char (32) unaligned;
where:
0. version
is set to CROSSREFERENCE_INFO_VERSION_1.
1. parent
is the name of the attribute a crossreference was requested
for.
2. reference_count
is the number of relations this attribute is referenced in.
3. child
is the name of the relation the specified attribute is
referenced within.
MTB-717 MTB-MRDS Model Manager
6.17: mrds_model_manager_$get_db_info
Name: mrds_model_manager_$get_db_info
This procedure returns information about the database that has
been stored in the MRDS data model.
Usage:
declare mrds_model_manager_$get_db_info entry
(fixed bin (35), ptr, char (*), fixed bin (35));
call mrds_model_manager_$get_db_info
(data_model_index, db_record_ptr, error_message,
code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. db_record_ptr (Input) (ptr)
is a pointer to the structure declared in
mmm_db_record.incl.pl1, which defines the information to be
returned about the database. The version field of this
structure must be specified so that the proper db_record
information is returned.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
MTB-MRDS Model Manager MTB-717
6.18: mrds_model_manager_$get_domain_info
Name: mrds_model_manager_$get_domain_info
This procedure returns information stored in the MRDS data model
about a single domain.
Usage:
declare mrds_model_manager_$get_domain_info entry
(fixed bin (35), ptr, char (*), fixed bin (35));
call mrds_model_manager_$get_domain_info
(data_model_index, domain_info_ptr, error_message,
code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. domain_info_ptr (Input) (ptr)
is a pointer to the structure declared in
mmm_domain_info.incl.pl1, which defines the information to
be returned about the specified domain. If this field is
null, no domain information will be returned; however the
existence of the domain is still verified. The version and
domain_name fields must be supplied by the caller.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The domain_info structure is defined as:
dcl 1 domain_info aligned based (domain_info_ptr),
2 version char (8) unaligned,
2 domain_name char (32) unaligned,
2 domain_descriptor bit (36),
2 decode_declare_data_descriptor bit (36),
2 check_procedure_path char (168) unaligned,
2 decode_procedure_path char (168) unaligned,
2 encode_procedure_path char (168) unaligned,
2 reference_count fixed bin (17);
where:
MTB-717 MTB-MRDS Model Manager
0. version
is set to DOMAIN_INFO_VERSION_1.
1. domain_name
is the name of the domain information was requested about.
2. domain_descriptor
is the underlying data type, described as a Multics PL/I
descriptor.
3. decode_declare_data_descriptor
is the data type to be used for the user's view and the
decode procedure, if present. If this field is not used, it
is set to "0"b.
4. check_procedure_path
is an absolute pathname pointing to the procedure to be
called to perform data verification checks upon storage into
the database. If this field is not to be used, it is set to
"".
5. decode_procedure_path
is an absolute pathname pointing to the procedure to be
called to perform data decoding upon retrieval from the
database. If this field is not to be used, it is set to "".
6. encode_procedure_path
is an absolute pathname pointing to the procedure to be
called to perform data encoding before storage into an
internal database form. If this field is not to be used, it
is set to "".
7. reference_count
is the number of attributes this domain is referenced in.
MTB-MRDS Model Manager MTB-717
6.19: mrds_model_manager_$get_domain_list
Name: mrds_model_manager_$get_domain_list
This procedure returns the number of domains defined within the
specified MRDS model, and optionally the list of names of all
domains defined.
Usage:
declare mrds_model_manager_$get_domain_list entry
(fixed bin (35), char (8), ptr, fixed bin (17),
ptr, char (*), fixed bin (35));
call mrds_model_manager_$get_domain_list
(data_model_index, name_list_version, user_area_ptr,
name_list_count, name_list_ptr, error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. name_list_version (Input) (char (8))
specifies which version of name_list structure to allocate.
3. user_area_ptr (Input) (ptr)
is a pointer to the area to create the name_list structure
within. If this field is null, no name_list structure is
allocated; however the number of defined domains is still
returned.
4. name_list_count (Output) (fixed bin (17))
is the number of domains defined.
5. name_list_ptr (Output) (ptr)
is a pointer to the structure declared in
mmm_name_list.incl.pl1, which defines the list of domain
names returned.
6. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
7. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The name_list structure is defined as:
MTB-717 MTB-MRDS Model Manager
dcl 1 name_list aligned based (name_list_ptr),
2 version char (8) unaligned,
2 count fixed bin (17),
2 name (name_list_count refer (name_list.count))
char (32) unaligned;
where:
0. version
is set to NAME_LIST_VERSION_1.
1. count
is the total number of domains defined within the MRDS
model.
2. name
is the name of the domain.
MTB-MRDS Model Manager MTB-717
6.20: mrds_model_manager_$get_domain_xref
Name: mrds_model_manager_$get_domain_xref
This procedure returns a list of attributes the specified domain
is referenced within, or an indication that it is unreferenced.
Usage:
declare mrds_model_manager_$get_domain_xref entry
(fixed bin (35), char (*), char (8), ptr,
ptr, fixed bin (17), char (*), fixed bin (35));
call mrds_model_manager_$get_domain_xref
(data_model_index, domain_name,
crossreference_info_version, user_area_ptr,
crossreference_info_ptr, reference_count,
error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. domain_name (Input) (char (*))
is the name of the domain about which the attribute crossref
is to be returned.
3. crossreference_info_version (Input) (char (8))
specifies which version of crossreference_info structure to
allocate.
4. user_area_ptr (Input) (ptr)
is a pointer to the area to create the crossreference_info
structure within. If this field is null, no
crossreference_info structure is allocated; however the
number of attributes this domain is referenced within is
still returned or an error code is returned if the domain
does not exist.
5. crossreference_info_ptr (Output) (ptr)
is a pointer to the structure declared in
mmm_crossreference_info.incl.pl1, which defines the
attribute crossreference to be returned about the specified
domain. If user_area_ptr is null, this field will be set to
null.
6. reference_count (Output) (fixed bin (17))
is the number of attributes the specified domain is
referenced in.
MTB-717 MTB-MRDS Model Manager
7. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
8. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The crossreference_info structure is defined as:
dcl 1 crossreference_info aligned based
(crossreference_info_ptr),
2 version char (8) unaligned,
2 parent char (32) unaligned,
2 reference_count fixed bin (17),
2 child (crossreference_info_reference_count refer
(crossreference_info.reference_count))
char (32) unaligned;
where:
0. version
is set to CROSSREFERENCE_INFO_VERSION_1.
1. parent
is the name of the domain information was requested about.
2. reference_count
is the number of attributes this domain is referenced in.
3. child
is the name of the attribute the specified domain is
referenced within.
MTB-MRDS Model Manager MTB-717
6.21: mrds_model_manager_$get_history
Name: mrds_model_manager_$get_history
This procedure retrieves the history data from the database model
information which indicates the last process that has
restructured the MRDS database, the process that created the
database, and the process that has the database quiesced (if
set).
Usage:
declare mrds_model_manager_$get_history entry
(fixed bin (35), ptr, char (*), fixed bin (35));
call mrds_model_manager_$get_history
(data_model_index, database_history_info_ptr,
error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. database_history_info_ptr (Input) (ptr)
is a pointer to the database_history_info structure declared
in mmm_history_info.incl.pl1, which defines the history
information to be returned. The version field of this
structure must be specified by the caller, to specify what
version of the database_history_info information is to be
returned.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
MTB-717 MTB-MRDS Model Manager
6.22: mrds_model_manager_$get_index_info
Name: mrds_model_manager_$get_index_info
This procedure returns information about indices in the specified
database data model for the indicated relation.
Usage:
declare mrds_model_manager_$get_index_info entry
(fixed bin (35), char (*), char (8), ptr, ptr,
fixed bin (17), char (*), fixed bin (35));
call mrds_model_manager_$get_index_info
(data_model_index, relation_name, index_info_version,
user_area_ptr, index_info_ptr, index_count,
error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. relation_name (Input) (char (*))
is the name of the relation to return index information for.
3. index_info_version (Input) (char (8))
specifies the version of index_info structure to allocate.
4. user_area_ptr (Input) (ptr)
is a pointer to the area to create the index_info structure
within. If this field is null, no index_info structure is
allocated; however the number of indices is still returned.
5. index_info_ptr (Output) (ptr)
is a pointer to the structure declared in
mmm_index_info.incl.pl1, which defines the information
returned about the indices for the specified relation.
6. index_count (Output) (fixed bin (17))
is the number of indices in the specified relation.
7. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
8. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The index_info structure is defined as:
MTB-MRDS Model Manager MTB-717
dcl 1 index_info aligned based (index_info_ptr),
2 version char (8) unaligned,
2 relation_name char (32) unaligned,
2 index_count fixed bin (17),
2 max_attribute_count fixed bin (17),
2 index (index_info_index_count refer
(index_info.index_count)),
3 name char (32) unaligned,
3 index_id bit (36) aligned,
3 attribute_count fixed bin (17) unaligned,
3 flags unaligned,
4 unique bit (1),
4 pad bit (17),
3 attribute_name
(index_info_max_attribute_count refer
(index_info.max_attribute_count))
char (32) unaligned;
where:
0. version
is set to INDEX_INFO_VERSION_1.
1. relation_name
is the name of the relation that contains the indices.
2. count
is the number of indices defined.
3. index_count
is the number of indices defined for this relation.
4. max_attribute_count
is the maximum number of attributes that are contained
within all the indices. The largest this count may be is
the number of attributes.
5. index.name
is the name specified by the creator of the index.
6. index.index_id
is a unique id which must be used for further references to
the relation managers.
7. index.attribute_count
is the number of attribute_name slots used for this index.
8. index.flags.unique
if set, indicates that the specified index describes a
unique key to the relation.
MTB-717 MTB-MRDS Model Manager
9. index.attribute_name
describes the set of attributes that comprise the specified
index.
MTB-MRDS Model Manager MTB-717
6.23: mrds_model_manager_$get_relation_info
Name: mrds_model_manager_$get_relation_info
This procedure returns information stored in the MRDS data model
about a single relation.
Usage:
declare mrds_model_manager_$get_relation_info entry
(fixed bin (35), char (*), char (8), ptr, ptr,
char (*), fixed bin (35));
call mrds_model_manager_$get_relation_info
(data_model_index, relation_name,
relation_info_version, user_area_ptr,
relation_info_ptr, error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. relation_name (Input) (char (*))
is the name of the relation to return information about.
3. relation_info_version (Input) (char (8))
is the version of relation_info structure to create.
4. user_area_ptr (Input) (ptr)
is a pointer to the area to create the relation_info
structure within. If this field is null, no relation_info
structure is allocated; however the existence of the
relation is still verified.
5. relation_info_ptr (Output) (ptr)
is a pointer to the structure declared in
mmm_relation_info.incl.pl1, which defines the information to
be returned about the specified relation.
6. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
7. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The relation_info structure is defined as:
MTB-717 MTB-MRDS Model Manager
dcl 1 relation_info aligned based (relation_info_ptr),
2 version char (8) unaligned,
2 relation_name char (32) unaligned,
2 count fixed bin (17),
2 type fixed bin (17) unaligned,
2 link_information,
3 flags unaligned,
4 link bit (1),
4 pad bit (17),
3 directory char (168) unaligned,
3 name char (32) unaligned,
2 attribute (relation_info_count refer
(relation_info.count)),
char (32) unaligned;
where:
0. version
is set to RELATION_INFO_VERSION_1.
1. relation_name
is the name of the relation to return information about.
2. count
is the number of attributes that are to comprise the
attribute set contained in the specified relation.
3. type
specifies the type of relation. The only supported relation
types are VFILE_TYPE and DMFILE_TYPE, defined in the include
file mmm_relation_types.incl.pl1.
4. link_information.flags.link
if set, implies this relation is a link relation.
relation_info.count will be set to zero. All fields other
than link_information.* and relation_name will not be set.
5. link_information.directory
specifies an absolute pathname to the foreign database,
including the database suffix.
6. link_information.name
specifies the name of the relation in the foreign database.
7. attribute.name
is the name of the attribute included in the relation. The
relation tuples consist of the set of attributes in the
order specified.
MTB-MRDS Model Manager MTB-717
6.24: mrds_model_manager_$get_relation_list
Name: mrds_model_manager_$get_relation_list
This procedure returns the number of relations defined within the
specified MRDS model, and optionally the list of names of all
relations defined.
Usage:
declare mrds_model_manager_$get_relation_list entry
(fixed bin (35), char (8), ptr, fixed bin (17),
ptr, char (*), fixed bin (35));
call mrds_model_manager_$get_relation_list
(data_model_index, name_list_version, user_area_ptr,
name_list_count, name_list_ptr, error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. name_list_version (Input) (char (8))
specifies which version of name_list structure to allocate.
3. user_area_ptr (Input) (ptr)
is a pointer to the area to create the name_list structure
within. If this field is null, no name_list structure is
allocated; however the number of defined relations is still
returned.
4. name_list_count (Output) (fixed bin (17))
is the number of relations defined.
5. name_list_ptr (Output) (ptr)
is a pointer to the structure declared in
mmm_name_list.incl.pl1, which defines the list of relation
names to be returned.
6. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
7. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The name_list structure is defined as:
MTB-717 MTB-MRDS Model Manager
dcl 1 name_list aligned based (name_list_ptr),
2 version char (8) unaligned,
2 count fixed bin (17),
2 name (name_list_count refer (name_list.count))
char (32) unaligned;
where:
0. version
is set to NAME_LIST_VERSION_1.
1. count
is the total number of relations defined within the MRDS
model.
2. name
is the name of the relation.
MTB-MRDS Model Manager MTB-717
6.25: mrds_model_manager_$initialize_model
Name: mrds_model_manager_$initialize_model
This procedure initializes the data model by deleting all
information kept within the model entries. The initialize model
operation is equivalent to calling
mrds_model_manager_$delete_model followed by calling
mrds_model_manager_$create_model.
Usage:
declare mrds_model_manager_$initialize_model entry
(fixed bin (35), char (*), fixed bin (35));
call mrds_model_manager_$intialize_model
(data_model_index, error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
3. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
MTB-717 MTB-MRDS Model Manager
6.26: mrds_model_manager_$modify_attribute
Name: mrds_model_manager_$modify_attribute
This procedure modifies the name or the underlying domain of a
single attribute.
Usage:
declare mrds_model_manager_$modify_attribute entry
(fixed bin (35), ptr, char (*), fixed bin (35));
call mrds_model_manager_$modify_attribute
(data_model_index, modify_attribute_request_ptr,
error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. modify_attribute_request_ptr (Input) (ptr)
is a pointer to the structure declared in
mmm_modify_attribute_rq.incl.pl1, which defines the
modifications to be made to the indicated attribute.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The modify_attribute_request structure is defined as:
dcl 1 modify_attribute_request aligned based (mar_ptr),
2 version char (8) unaligned,
2 flags unaligned,
3 new_name bit (1),
3 new_domain bit (1),
3 reserved bit (34),
2 attribute_name char (32) unaligned,
2 new_name char (32) unaligned,
2 new_domain char (32) unaligned;
where:
0. version
is set to MODIFY_ATTRIBUTE_VERSION_1.
MTB-MRDS Model Manager MTB-717
1. flags.new_name
is set to "1"b if the new_name field is specified.
2. flags.new_domain
is set to "1"b if the new_domain field is specified.
3. attribute_name
is the name of the attribute to be modified.
4. new_name
specifies the new name of the attribute if flags.new_name is
set.
5. new_domain
specifies the new underlying domain of the attribute if
flags.new_domain is set. If the attribute is referenced in
any relations, the referenced relations are reformatted and
the attribute undergoes data conversion to the new data
type. If an error occurs during data conversion, the
attribute will not be modified and an error message and code
will be returned.
MTB-717 MTB-MRDS Model Manager
6.27: mrds_model_manager_$modify_domain
Name: mrds_model_manager_$modify_domain
This procedure modifies the name, the underlying data type, or
the various procedures that may be specified for a single domain.
Usage:
declare mrds_model_manager_$modify_domain entry
(fixed bin (35), ptr, char (*), fixed bin (35));
call mrds_model_manager_$modify_domain
(data_model_index, modify_domain_request_ptr,
error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. modify_domain_request_ptr (Input) (ptr)
is a pointer to the structure declared in
mmm_modify_domain_rq.incl.pl1, which defines the
modifications to be made to the indicated domain.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The modify_domain_request structure is defined as:
dcl 1 modify_domain_request aligned based (mdr_ptr),
2 version char (8) unaligned,
2 domain_name char (32) unaligned,
2 flags unaligned,
3 new_domain_descriptor bit (1),
3 new_domain_name bit (1),
3 new_decode_declare_data_descriptor bit (1),
3 new_check_procedure bit (1),
3 new_decode_procedure bit (1),
3 new_encode_procedure bit (1),
3 reserved bit (30),
2 new_domain_descriptor bit (36),
2 new_domain_name char (32) unaligned,
2 new_decode_declare_data_descriptor bit (36),
2 check_procedure_path char (168) unaligned,
MTB-MRDS Model Manager MTB-717
2 decode_procedure_path char (168) unaligned,
2 encode_procedure_path char (168) unaligned;
where:
0. version
is set to MODIFY_DOMAIN_VERSION_1.
1. domain_name
is the name of the domain to be modified.
2. flags.new_domain_descriptor
is set to "1"b if the new_domain_descriptor field is
specified.
3. flags.new_domain_name
is set to "1"b if the new_domain_name field is specified.
4. flags.new_decode_declare_data_descriptor
is set to "1"b if the new_decode_declare_data_descriptor
field is specified.
5. flags.new_check_procedure
is set to "1"b if the new_check_procedure_path field is
specified.
6. flags.new_decode_procedure
is set to "1"b if the new_decode_procedure_path is
specified.
7. flags.new_encode_procedure
is set to "1"b if the new_encode_procedure_path is
specified.
8. new_domain_descriptor
is the new underlying data type, described as a standard
Multics descriptor. The list of supported data types are
described in Appendix B.
9. new_decode_declare_data_descriptor
is the data type to be used for the user's view and the
decode procedure, if present.
10. check_procedure_path
is an absolute pathname pointing to the procedure to be
called to perform data verification checks upon storage into
the database. If this field is not specified, it must be
set to "".
11. decode_procedure_path
is an absolute pathname pointing to the procedure to be
called to perform data decoding upon retrieval of data from
MTB-717 MTB-MRDS Model Manager
the database. If this field is not specified, it must be
set to "".
12. encode_procedure_path
is an absolute pathname pointing to the procedure to be
called to perform data encoding before storate into an
internal database forum. If this field is not specified, it
must be set to "".
MTB-MRDS Model Manager MTB-717
6.28: mrds_model_manager_$modify_relation
Name: mrds_model_manager_$modify_relation
This procedure modifies the name, type of relation, or the list
of attributes contained within a specified relation. Attributes
that are to be added to the relation are required to have an
initial value.
Usage:
declare mrds_model_manager_$modify_relation entry
(fixed bin (35), ptr, char (*), fixed bin (35));
call mrds_model_manager_$modify_relation
(data_model_index, modify_relation_request_ptr,
error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. modify_relation_request_ptr (Input) (ptr)
is a pointer to the structure declared in
mmm_modify_relation_rq.incl.pl1, which defines the
modifications to be made to the indicated relation.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The modify_relation_request structure is defined as:
dcl 1 modify_relation_request aligned based (mrr_ptr),
2 version char (8) unaligned,
2 relation_name char (32) unaligned,
2 flags unaligned,
3 new_relation_name bit (1),
3 new_relation_type bit (1),
3 reserved bit (34),
2 new_relation_name char (32) unaligned,
2 new_relation_type,
3 type fixed bin (17),
3 mode_string char (256) unaligned,
2 total_initial_value_lengths fixed bin (17),
2 action_count fixed bin (17),
MTB-717 MTB-MRDS Model Manager
2 action (modify_relation_request_action_count refer
(modify_relation_request.action_count)),
3 attribute_name char (32) unaligned
3 initial_value_idx fixed bin (17) unaligned,
3 initial_value_length fixed bin (17) unaligned,
3 type fixed bin (17),
2 initial_values char
(modify_relation_request.total_initial_value_lengths);
0. version
is set to MODIFY_RELATION_VERSION_1;
1. relation_name
is the name of the relation that is to be modified.
2. flags.new_relation_name
is set to "1"b if the new_relation_name field is specified.
3. flags.new_relation_type
is set to "1"b if the new_relation_type fields are
specified.
4. new_relation_name
specifies the name that the relation is to be renamed to.
5. new_relation_type.type
specifies the type of relation that it is to be converted
to. The only types currently supported are VFILE_TYPE and
DMFILE_TYPE, defined in the include file
mmm_relation_types.incl.pl1.
6. new_relation_type.mode_string
is used if the new relation type supports various modes,
otherwise it must be set to "".
7. initial_value_lengths
is the sum of the lengths of all the initial value strings.
8. action_count
is the number of actions (adds or deletes) that are to be
performed upon the relation.
9. action.attribute_name
is the name of the attribute that is to be added to or
deleted from the relation.
10. action.initial_value_idx
is the starting character position in the initial_values
string of the initial value for this attribute.
11. action.initial_value_length
is the length of the character string which is the initial
MTB-MRDS Model Manager MTB-717
value string for this attribute. The length of the initial
value string may be zero, indicating a null string; however
all attributes to be added to the relation must have some
specified initial value.
12. action.type
specifies the type of action to be performed upon this
attribute. The only types supported are ADD_ACTION and
DELETE_ACTION, declared in the include file
mmm_modify_relation_rq.incl.pl1.
13. initial_values
is the concatenation of all the initial value strings for
all the attributes to be added.
MTB-717 MTB-MRDS Model Manager
6.29: mrds_model_manager_$open_model
Name: mrds_model_manager_$open_model
This procedure is used to indicate that a model is to be opened
for use by MRDS. The model index returned is to be used in all
further calls to the mrds_model_manager_.
Usage:
declare mrds_model_manager_$open_model entry
(char (*), char (*), fixed bin (17),
fixed bin (35), char (*), fixed bin (35));
call mrds_model_manager_$open_model (db_directory_name,
db_entry_name, open_mode, database_model_index,
error_message, code);
Arguments:
1. db_directory_name (Input) (char (*))
is the directory portion of the MRDS database pathname.
2. db_entry_name (Input) (char (*))
is the entry portion of the MRDS database pathname, with or
without the database suffix.
3. open_mode (Input) (fixed bin (17))
is the mode that the model is to be used in. The supported
modes are READ_ONLY_MODE and MODIFY_MODE, defined in the
include file mmm_model_modes.incl.pl1.
4. db_model_index (Output) (fixed bin (35))
is the index that indicates to all subsequent calls to
mrds_model_manager_ which database data model to operate
upon.
5. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
6. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
MTB-MRDS Model Manager MTB-717
6.30: mrds_model_manager_$quiesce_model
Name: mrds_model_manager_$quiesce_model
This procedure sets the quiesce flag in the database model
information to indicate that the MRDS database model is not to be
opened for further use.
Usage:
declare mrds_model_manager_$quiesce_model entry
(fixed bin (35), ptr, char (*), fixed bin (35));
call mrds_model_manager_$quiesce_model
(data_model_index, command_info_ptr, error_message,
code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. command_info_ptr (Input) (ptr)
is a pointer to the command_info structure declared in
mmm_history_info.incl.pl1, which defines the information to
be stored in the model about the subsystem that is quiescing
the specified model.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
MTB-717 MTB-MRDS Model Manager
6.31: mrds_model_manager_$secure_database
Name: mrds_model_manager_$secure_database
This procedure secures a database. Only the DBA may secure a
database. A secured database may be opened only by the DBA
without referencing the model through a submodel. It also
implies processing on the data contained within the database is
done in a lower ring, allowing only user accessible data to be
returned to the outer ring.
Usage:
declare mrds_model_manager_$secure_database entry
(char (*), char (*), char (*), fixed bin (35));
call mrds_model_manager_$secure_database
(db_directory_name, db_entry_name, error_message,
code);
Arguments:
1. db_directory_name (Input) (char (*))
is the directory portion of the MRDS database pathname.
2. db_entry_name (Input) (char (*))
is the entry portion of the MRDS database pathname, with or
without the database suffix.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
MTB-MRDS Model Manager MTB-717
6.32: mrds_model_manager_$set_db_info
Name: mrds_model_manager_$set_db_info
This procedure returns information about the database that has
been stored in the MRDS data model.
Usage:
declare mrds_model_manager_$set_db_info entry
(fixed bin (35), ptr, char (*), fixed bin (35));
call mrds_model_manager_$set_db_info
(data_model_index, db_info_ptr, error_message,
code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. db_info_ptr (Input) (ptr)
is a pointer to the structure declared in
mmm_db_info.incl.pl1, which defines the information to be
stored in the model about the database.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
Notes: The db_info structure is defined as:
dcl 1 db_info aligned based (db_info_ptr),
2 version char (8) unaligned,
2 flags unaligned,
3 before_journalizing bit (1),
3 concurrency bit (1),
3 pad bit (16),
2 default_relation_type fixed bin (17);
where:
0. version
is set to DB_INFO_VERSION_1.
MTB-717 MTB-MRDS Model Manager
1. before_journalizing
if set, implies that before journals are to be started to be
used for the DM files in this database.
2. concurrency
if set, implies that DM file concurrency is to be started to
be used for the DM files in this database.
3. default_relation_type
if set to a nonzero value, indicates the new default
relation type. The only supported types are VFILE_TYPE and
DMFILE_TYPE, declared in the include file
mmm_relation_types.incl.pl1.
MTB-MRDS Model Manager MTB-717
6.33: mrds_model_manager_$set_restructure_history
Name: mrds_model_manager_$set_restructure_history
This procedure sets the history data in the database model
information to indicate the last process that restructured the
MRDS database. The history information may be displayed with the
display_mrds_db_status command.
Usage:
declare mrds_model_manager_$set_restructure_history entry
(fixed bin (35), ptr, char (*),
fixed bin (35));
call mrds_model_manager_$set_restructure_history
(data_model_index, restructure_info_ptr,
error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. command_info_ptr (Input) (ptr)
is a pointer to the command_info structure declared in
mmm_history_info.incl.pl1, which defines the information to
be stored in the model about the command restructuring the
database.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
MTB-717 MTB-MRDS Model Manager
6.34: mrds_model_manager_$unquiesce_model
Name: mrds_model_manager_$unquiesce_model
This procedure sets the quiesce flag in the database model
information to indicate that the MRDS database model is available
to be opened.
Usage:
declare mrds_model_manager_$unquiesce_model entry
(fixed bin (35), char (*), fixed bin (35));
call mrds_model_manager_$unquiesce_model
(data_model_index, error_message, code);
Arguments:
1. data_model_index (Input) (fixed bin (35))
is the index returned by mrds_model_manager_$open_model that
designates the database.
2. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
3. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
MTB-MRDS Model Manager MTB-717
6.35: mrds_model_manager_$unsecure_database
Name: mrds_model_manager_$unsecure_database
This procedure unsecures a database, reversing the action of
mrds_model_manager_$secure_database. Only the DBA may unsecure a
database.
Usage:
declare mrds_model_manager_$unsecure_database entry
(char (*), char (*), char (*), fixed bin (35));
call mrds_model_manager_$unsecure_database
(db_directory_name, db_entry_name, error_message,
code);
Arguments:
1. db_directory_name (Input) (char (*))
is the directory portion of the MRDS database pathname.
2. db_entry_name (Input) (char (*))
is the entry portion of the MRDS database pathname, with or
without the database suffix.
3. error_message (Output) (char (*))
is a printable error message that is returned if the code
argument is set to a non-zero value.
4. code (Output) (fixed bin (35))
is a standard status code. A value of 0 indicates that no
error occurred.
MTB-717 MTB-MRDS Model Manager
APPENDIX A: DM FILE RECORD DEFINITIONS
This appendix defines the different types of records that make up
the MRDS data model. These records are stored within a DM file,
and operated upon only with the mrds_model_manager_ interface.
A.1: mmm_attribute_record.incl.pl1
dcl 1 attribute_record aligned based (attribute_record_ptr),
2 version char (8) unaligned,
2 name char (32) unaligned,
2 domain char (32) unaligned,
2 reference_count fixed bin (17);
where:
version
is set to ATTRIBUTE_RECORD_VERSION_1.
name
is the name of the attribute this structure defines.
domain
is the name of the underlying domain.
reference_count
is the number of relations that contain this attribute.
MTB-MRDS Model Manager MTB-717
A.2: mmm_attribute_xref_rec.incl.pl1
dcl 1 attribute_xref_record aligned based
(attribute_xref_record_ptr),
2 version char (8) unaligned,
2 attribute_name char (32) unaligned,
2 relation_count fixed bin (17),
2 relation_name (attribute_xref_record_relation_count
refer (attribute_xref_record.relation_count)),
char (32) unaligned;
where:
version
is set to ATTRIBUTE_XREF_RECORD_VERSION_1;
attribute_name
is the name of the attribute this structure defines.
relation_count
is the number of relations that reference this attribute.
relation_name
is the name of the relations that reference this attribute.
MTB-717 MTB-MRDS Model Manager
A.3: mmm_db_record.incl.pl1
dcl 1 db_record aligned based (db_record_ptr),
2 version char (8) unaligned,
2 flags unaligned,
3 before_journalizing bit (1),
3 concurrency bit (1),
3 transactions_needed bit (1),
3 secured bit (1),
3 quiesced bit (1),
3 pad (13),
2 default_relation_type fixed bin (17) unaligned,
2 create_history like history_info,
2 change_history like history_info,
2 quiesce_history like history_info;
where:
version
is set to DB_RECORD_VERSION_1.
flags.before_journalizing
if set, implies that before journals are to be taken for the
DM files in this database.
flags.concurrency
if set, implies that DM file concurrency is to be used.
flags.transactions_needed
if set, implies that at least one relation contained within
this MRDS database is a DM file, thus MRDS must run under a
transaction.
flags.secured
if set, implies that the MRDS database is secured. This
means that only the DBA is allowed to reference this
database through the model; all other users must use a
submodel. It also implies that all check, encode, decode
procedures, and all data files must reside in ring 2.
flags.quiesced
if set, implies that attempts to open this database are to
fail. The quiesce_history field will indicate who and when
the database was quiesced.
default_relation_type
specifies the type of relation to create by default if the
type is not specified at relation creation time. The only
types supported are VFILE_TYPE and DMFILE_TYPE, defined in
mmm_relation_types.incl.pl1.
MTB-MRDS Model Manager MTB-717
create_history
specifies information about the process that created the
database.
change_history
specifies information about the process that last changed
this database record.
quiesce_history
specifies information about the process that has the
database quiesced. If the database is not quiesced, this
field is not used.
MTB-717 MTB-MRDS Model Manager
A.4: mmm_domain_record.incl.pl1
dcl 1 domain_record aligned based (domain_record_ptr),
2 version char (8) unaligned,
2 name char (32) unaligned,
2 flags unaligned,
3 no_conversion bit (1),
3 encode_proc bit (1),
3 decode_proc bit (1),
3 check_proc bit (1),
3 pad bit (14),
2 reference_count fixed bin (17) unaligned,
2 db_descriptor bit (36),
2 user_descriptor bit (36),
2 encode_path char (168) unaligned,
2 decode_path char (168) unaligned,
2 check_path char (168) unaligned;
where:
version
is set to DOMAIN_RECORD_VERSION_1.
name
is the name of the domain this structure defines.
flags.no_conversion
if set, implies no conversion of this domain is allowed.
flags.encode_proc
if set, implies the encode_path field is specified.
flags.decode_proc
if set, implies the decode_path field is specified.
flags.check_proc
if set, implies the check_path field is specified.
db_descriptor
is the definition of this domain in the database, expressed
in terms of a Multics PL/I descriptor word.
user_descriptor
is the definition of this domain in a user visible format,
expressed in terms of a standard Multics descriptor word.
The list of supported data types are defined in Appendix B.
reference_count
is the number of attributes defined upon this domain.
encode_path
if specified, is an absolute pathname to the procedure to be
MTB-MRDS Model Manager MTB-717
called when data encoding before storage into a database is
performed.
decode_path
if specified, is an absolute pathname to the procedure to be
called when data decoding upon retrieval is performed.
check_path
if specified, is an absolute pathname to the procedure to be
called when data verification before storage into a database
is performed.
MTB-717 MTB-MRDS Model Manager
A.5: mmm_domain_xref_record.incl.pl1
dcl 1 domain_xref_record aligned based
(domain_xref_record_ptr),
2 version char (8) unaligned,
2 domain_name char (32) unaligned,
2 attribute_count fixed bin (17),
2 attribute_name (domain_xref_record_attribute_count
refer (domain_xref_record.attribute_count)),
char (32) unaligned;
where:
version
is set to DOMAIN_XREF_RECORD_VERSION_1.
domain_name
is the name of the domain this structure defines.
attribute_count
is the number of attributes based upon this domain.
attribute_name
is the name of the attributes based upon this domain.
MTB-MRDS Model Manager MTB-717
A.6: mmm_history_info.incl.pl1
dcl 1 database_history_info aligned
based (database_history_info_ptr),
2 create_history like history_info,
2 restructure_history like history_info,
2 quiesce_history like history_info;
where:
create_history
defines the process and date_time the database was created.
restructure_history
defines the process and date_time the database was last
restructured. If the database has never been restructured,
restructure_history.date_time is set to zero.
quiesce_history
defines the process and date_time the database was quiesced.
If the database is not quiesced, quiesce_history.date_time
is set to zero.
dcl 1 history_info aligned based (history_info_ptr),
2 version char (8) unaligned,
2 command like command_info,
2 personid char (32) unaligned,
2 date_time fixed bin (71);
where:
version
is set to HISTORY_INFO_VERSION_1.
command.name
is the name of the subsystem or command that is currently
executing.
command.version
is the version of the subsystem or command that is currently
executing.
personid
is the Person.Project.tag of the process.
date_time
is a clock value that may be converted by use of the
date_time_ subroutine.
dcl 1 command_info aligned based (command_info_ptr),
2 name char (32) unaligned,
2 version char (32) unaligned;
MTB-717 MTB-MRDS Model Manager
where:
name
is the name of the command or subsystem that is making the
quiesce request.
version
is the version of the command or subsystem referenced in the
command_name field.
MTB-MRDS Model Manager MTB-717
A.7: mmm_relation_record.incl.pl1
dcl 1 relation_record aligned based (relation_record_ptr),
2 version char (8) unaligned,
2 name char (32) unaligned,
2 id bit (36) aligned,
2 type fixed bin (17) unaligned,
2 flags unaligned,
3 indexed bit (1),
3 link bit (1),
3 pad bit (15),
2 max_tuples fixed bin (35),
2 max_data_length fixed bin (35),
2 max_key_length fixed bin (35),
2 varying_offset fixed bin (35),
2 number_attributes fixed bin (17) unaligned,
2 number_key_attributes fixed bin (17) unaligned,
2 number_varying_attributes fixed bin (17) unaligned,
2 tuple_id_length fixed bin (17) unaligned,
2 index_count fixed bin (17) unaligned,
2 max_attribute_index_count fixed bin (17) unaligned,
2 default_ring_brackets (3) fixed bin (8) unaligned,
2 primary_key_index_id bit (36) aligned,
2 link_directory char (168) unaligned,
2 link_name char (32) unaligned,
2 attribute (relation_record_attribute_count refer
(relation_record.attribute_count)),
3 name char (32) unaligned,
2 index (relation_record_index_count refer
(relation_record.index_count)),
3 name char (32) unaligned,
3 id bit (36) aligned,
3 attribute_count fixed bin (17) unaligned,
3 flags unaligned,
4 unique bit (1),
4 pad bit (17),
3 attribute_name
(relation_record_max_attribute_index_count refer
(relation_record.max_attribute_index_count))
char (32) unaligned;
where:
version
is set to RELATION_RECORD_VERSION_1.
name
is the name of the relation that is specified by this
structure.
MTB-717 MTB-MRDS Model Manager
id
is a unique file id for this relation. It is unique across
the Multics file system.
type
is the type of relation. The only supported types are
VFILE_TYPE and DMFILE_TYPE, defined in
mmm_relation_types.incl.pl1.
flags.indexed
if set, indicates that there is at least one index other
than the primary key.
flags.link
if set, specifies that this relation structure defines a
link relation. No other fields will be set except for the
link_directory and link_name fields.
max_tuples
specifies the maximum number of tuples allowed in this
relation.
max_data_length
specifies the maximum length of the data portion of each
tuple, in bytes.
max_key_length
specifies the maximum length of the key portion of each
tuple, in bytes.
varying_offset
specifies the column position of the first varying
attribute.
number_attributes
is the total number of attributes (columns) that make up
each tuple.
number_key_attributes
is the number of attributes (columns) that make up the key
portion of each tuple.
number_varying_attributes
is the number of varying attributes in each tuple.
tuple_id_length
is the length of the tuple id, in bits.
index_count
is the number of indices that have been created in this
relation.
MTB-MRDS Model Manager MTB-717
max_attribute_index_count
is the maximum number of attributes that are contained
within all the indices. The largest this count may be is
the number of attributes.
default_ring_brackets
are the ring brackets of the relation that contains the data
when it was created.
primary_key_index_id
specifies the index id of the relation's primary key.
link_directory
if set, specifies the directory that contains the data
relation in a foreign database.
link_name
if set, specifies the name of the data relation in a foreign
database.
attribute.name
is the name of the attribute (column) in the tuple.
index.name
is the name specified by the creator of the index.
index.id
is a unique id must be used for further references to the
relation managers.
index.attribute_count
is the number of attribute_name slots used for this index.
index.flags.unique
if set, indicates that the specified index describes a
unique key to the relation.
index.attribute_name
describes the set of attributes that comprise the specified
index.
MTB-717 MTB-MRDS Model Manager
APPENDIX B: SUPPORTED DATA TYPES
The data types supported for descriptors are:
Real binary - data types 1 through 4
Complex binary - data types 5 through 8
Real decimal - data types 9 and 10
Complex decimal - data types 11 and 12
Strings - data types 19 through 22
Unsigned real binary - data types 33 and 34
Real decimal - data types 43 and 44
Complex decimal - data types 45 and 46
All data must be scalar (i.e., arrays are not supported). Both
aligned and unaligned data is valid.