Multics Technical Bulletin MTB-739
System Dev. & Support Fac.
To: Distribution
From: Lee A. Newcomb
Date: 02/27/86
Subject: Systems' Development and Support Facilities
1 ABSTRACT
There are several different systems development and support
facilities used for the Multics system. Many are private tools
which have proven their value over the years. These facilities
do not have common interfaces or conventions, and are not
complete by themselves. The DPS6 follow-on (new) operating
system (NOS) development also requires high quality development
and configuration management tools.
The objective of this project is to install a consistent,
unified, and generally extensible set of these tools for NOS and
Multics development and maintenance. This MTB covers the general
philosophy and design of the Systems' Development and Support
Facilities (SDSF), and its first phase implementation.
Comments should be sent to the author:
via Multics Forum:
>udd>m>mtgs>Software_Development_Tools -at System-M
via Multics Mail:
Newcomb -at System-M
via Telephone:
(HVN) 492-9341, or (617) 492-9341
_________________________________________________________________
Multics project internal working documentation. Not to be
reproduced or distributed outside the Multics project without the
consent of the author or the author's management.
Multics Technical Bulletin MTB-739
CONTENTS
Page
1 Abstract . . . . . . . . . . . . . i
2 Introduction . . . . . . . . . . . 1
3 Requirements . . . . . . . . . . . 2
3.1 Software Configuration
Management . . . . . . . . . . . . 2
3.1.1 Change Requests . . . . . 2
3.1.2 Modification Tracking . . 3
3.1.3 System Integration
Requests . . . . . . . . . . . 3
3.1.4 Installation Auditing . . 3
3.1.5 Installation Tracking . . 4
3.1.6 Installation of
Development Modules . . . . . . 4
3.2 Multiple Libraries/Systems . . 4
3.3 Module Management . . . . . . . 5
3.3.1 Module Opening and
Installation . . . . . . . . . 6
3.3.2 Versioning . . . . . . . . 6
3.4 Problem Detection . . . . . . . 6
3.5 (Sub)System Building . . . . . 7
4 Existing Tools . . . . . . . . . . 7
4.1 Installed Multics Commands . . 7
4.2 Multics/MCR Tools . . . . . . . 8
4.3 Subsystem exec_com's and Vector
DBs . . . . . . . . . . . . . . . 8
4.4 ACTC FORTRAN Maintenance
exec_com's . . . . . . . . . . . . 9
5 Other Systems . . . . . . . . . . . 9
6 Initial Design . . . . . . . . . . 10
6.1 Databases . . . . . . . . . . . 10
6.1.1 Per-Library Definition
Database . . . . . . . . . . . 10
6.1.2 Per-Subsystem Database . . 11
6.2 Finding Libraries and
Subsystems . . . . . . . . . . . . 11
6.3 Description of the library
Command . . . . . . . . . . . . . 12
7 Problems . . . . . . . . . . . . . 12
8 References . . . . . . . . . . . . 12
Appendix A - Per-library Data Model . 14
Appendix B - Per-subsystem Data Model 17
CONTENTS (cont)
Page
Appendix C - library Command
Description . . . . . . . . . . . . . 21
library . . . . . . . . . . . . . . 21
System Dev. & Support Fac.
2 INTRODUCTION
Multics has long been one of the best systems development
and maintenance systems in existence. Its facilities include
high level languages, excellent debugging subsystems, a good
philosophy of software development, good editors, online
documentation, and a good configuration management policy; these
facilities are not discussed for the remainder of this paper as
they are assumed to be available. Many of these items, taken for
granted by Multics users, have become standard parts of newer
systems. The recent B2 security evaluation has helped make the
already good Multics software configuration management even
better.
However, other vendors and recent developments are leaving
Multics' tools in the dust. Several commercial products have
been introduced which are as good as the Multics tools, and cover
more areas of the systems support environment than Multics. Many
of these areas are covered by private tools on Multics; and,
while useful, are at times difficult to use together. Some
common problems are:
a) not all developers know of a tool's existence;
b) one developer may want a tool changed to better suit his
work habits; many times creating multiple copies of a tool
with increasing divergence from the original operation and
interface; or
c) one developer's tool is considered too slow for the benefits
received by others.
The object of this project is to install a high quality
system's development and support facilities (SDSF). This package
will be used to aid Multics maintenance thru the next decade and
to develop the DPS6/MOD400 follow-on (new) operating system
(NOS). The emphasis is on how to support the system library and
its subsystems; however, the design also supports individual and
project libraries so private, third party, and completely new
product investigations can be easily managed.
Much of the following is based on Multics' B2 configuration
management and the subsys tools written by Lindsey Spratt and
Matt Pierret. Many of the terms used below have roots in
Multics, but have been generalized for NOS usage.
MTB-739 Multics Technical Bulletin
System Dev. & Support Fac.
3 REQUIREMENTS
There are several requirements for SDSF. The major ones are
reviewed below. There is a general requirement of expandability
as the first implementation of SDSF will not cover the complete
set of all useful tools. The tools are expected to be added to
as resources become available and as new functionality is needed.
Expected improvements in database technology must also be usable,
such as distributed DBs.
Of all the requirements below, the availability of library
databases and development checkout and installation tools are the
foremost. The reason for the more comprehensive presentation is
to avoid problems other tools have encountered in the past of
tacking on interfaces not originally allowed for, with resulting
interface and database problems.
3.1 Software Configuration Management
Multics received a B2 security rating in August 1985 from
the National Computer Security Center (NCSC). As part of this
effort, the configuration management policies have been
formalized and new tools written to aid in using/enforcing these
policies. The following are some major configuration management
policies which SDSF must support. The reader is referred to the
Multics Administrative Bulletins, or MABs, listed in the
"References" section for more details.
3.1.1 CHANGE REQUESTS
To modify a system module, a system change request (SCR)
must first be approved; these are known as Multics Change
Requests, or MCRs, for Multics development. A user may not
request modules to be installed unless such an SCR has been
acquired. It is recommended modules be examined before
submitting a SCR and the SCR'd changes to the modules not be done
until the SCR is approved; however, this is not always possible.
SCRs should be marked satisfied when the change is installed.
3.1.2 MODIFICATION TRACKING
Each change the developer makes to a source module must be
summarized in that module. This is currently done via the
Multics history_comment (hcom) command. For more information on
hcom, the reader should see its online documentation. An SCR
will be rejected if all the modules contained in it have not had
their modification history updated, or have no such section at
all.
Multics Technical Bulletin MTB-739
System Dev. & Support Fac.
3.1.3 SYSTEM INTEGRATION REQUESTS
When a developer is ready to integrate his changes with the
current system, a system integration request (SIR) is filled out;
these are known as Multics System Change Requests, or MSCRs, in
the current organization. The SIR lists all modules to be
installed (whether modified, needs recompiling, etc.), what
directory the system integration unit can find the modules for
official installation, and any special instructions for the
integration process. An SIR must reference one or more approved
SCRs, be a critical fix, or have special management approval in
order for the modules in the SIR to be installed.
When special management approval is given, the reasons must
be recorded in the SIR as to why installation approval was
granted. The record must show the rationale behind not following
standard procedures. The library keeper will reject any SIRs
with this approval type lacking this information.
3.1.4 INSTALLATION AUDITING
Several steps occur between the time the developer fills out
the SIR and the installer receives it. One of the most important
of these is peer auditing; the developer picks another developer
(the auditor) who is qualified to examine the modules being
installed for problems. If the auditor passes the modules
(normal case), he records this fact, along with any non-failing
audit comments, and passes the SIR on to the documentation unit
for review. If any of the modules fail, all comments and the SIR
are passed back to the developer for correction. A module may
not be installed with any failing audit comments outstanding.
If there are changes to the system's Trusted Computing Base
(TCB), the security auditor must also examine the TCB changes;
again, failure causes the SIR to be kicked back to the developer
for correction and passage results in forwarding of the SIR to
the documentation unit.
A documentation unit member must sign off on the SIR to
indicate either 1) no documentation changes are necessary, or 2)
all information to update the user documentation has been
received and any online info files in the SIR are correct in
content and format. The changes required to a particular manual
are recorded with a notation as to what SCR/SIR the changes can
be found in. It is still the developer's responsibility to have
all upgraded documentation in the installation, however.
The SIR then passes to the developer's manager for approval
and forwarding to the systems integration unit.
MTB-739 Multics Technical Bulletin
System Dev. & Support Fac.
3.1.5 INSTALLATION TRACKING
All changes to the system must be tracked and be able to be
summarized. This is currently done via filing of SIRs,
Installations.log and Installations.info (*.changes.info)
segments, and to some extent the system release bulletin (SRB)
and system installation bulletin (SIB). This information must be
kept in a way that allows dependencies between installations to
be easily detected; this helps prevent inconsistent backouts and
the premature freeing of modules for more work (see "Module
Opening and Installation" below).
3.1.6 INSTALLATION OF DEVELOPMENT MODULES
All modules must go through an experimental phase before
being installed in a system library. A hierarchy exists for this
phase of a module. The above configuration management steps may
be done before the experimental copy is installed, but in this
case, the developer will act as the installer and no SIR is
created. If the experimental version is audited, the results are
recorded. When the SIR is submitted, the auditor is provided the
results of any previous audits, including information on whether
the module has changed since the audit.
A user may also define one or more developmental phases
lower than the experimental phase; this is commonly done with
large projects (e.g., Multics Data Management went through two
phases, development and bound_development, before reaching the
experimental phase). In this case, modules do not require an SCR
to be installed, and generally auditing is not done. However, a
module's modification history must still be maintained.
3.2 Multiple Libraries/Systems
SDSF must handle multiple libraries (and multiple systems
someday). Examples of libraries are the system library, a user's
or project's private library, and a third party's software
library. These libraries have various properties; e.g.: various
subsystems, access permissions for use and installation, content
types, and what notifications are to be sent for an installation.
Multics Technical Bulletin MTB-739
System Dev. & Support Fac.
A library is ideally a set of modules related by common
purpose or functionality, including source, executable, and
documentation modules. A library usually consists of more than
one hierarchy holding the library's modules (e.g., the Multics
system library uses >system_library_standard, >system_library_1,
>library_dir_dir, >experimental, etc.); a hierarchy does not
contain modules from more than library. N.B., this is not a
proposal to totally restructure the Multics library hierarchy,
the above mentioned directories will continue to be used, but
other directories will also be handled by SDSF (e.g.,
>udd>m>dms_sys>dms.ssd).
This is a deviation from the current definition of a library
on Multics. SDSF allows subsystems within a library,
particularly if the library is very large (e.g., the system
library). Examples of subsystems in the Multics system library
are: the hardcore supervisor, data_management, MRDS, mail
system, and the answering service. The reasons for allowing
subsystems are: a) to allow the assigning of access to a
specific subsystem to avoid accidental damage, and b)
distributing developmental versions of modules through the
hierarchy.
Currently, Multics development is distributed over multiple
systems. This distribution of effort is expected to carry over
to NOS development. Thus SDSF must be easily upgradable to
directly supporting distributed databases. The handling of
distributed systems will continue to be done "by hand" as is
currently done between System-M, CISL, ACTC, and MIT, with some
tools to aid in this effort.
3.3 Module Management
The basic element of a library is a module. These are used
to build executable units, subsystems, commands, etc., and to do
other random tasks (e.g., access control). All modules are part
of a library, and a library's subsystem; and thus are registered
in the library database and the appropriate subsystem database.
A module's various properties are also registered: what bound
unit holds the module, version, current disposition, and special
attributes (e.g., ring brackets and access settings) are a few.
The reader is referred to the data models in the appendicies for
the SDSF databases' proposed structures.
MTB-739 Multics Technical Bulletin
System Dev. & Support Fac.
3.3.1 MODULE OPENING AND INSTALLATION
A module must be opened before modifications are made to it;
the terms "locked" and "checked out" are also used for this
operation, but we will generally use "opened" in this paper.
Opening a module protects the user's work. Another user cannot
work on the same module without both users being aware of it;
possibly preventing duplicate work or causing one developer's
work to be invalidated. The SDSF tools will refuse to work for
any module which has not been opened; in particular, the auditing
and installation tools will not function.
Tools will be provided to aid in the processing of each step
of an installation, for all phases of libraries. Developers will
be able to install into the development and experimental phase,
but a library's access is constructed so only one of the
library's integration group may do final installations. For many
private libraries, the distinction is unnecessary.
3.3.2 VERSIONING
To aid the user during development and support, versions of
modules are maintained. These versions are used for auditing,
passing on enhancements and corrections to sites, and backing up
to a known version. Complete copies of a version are kept for
each shipped release (e.g., MR10.2, MR11.0, MOD400 Release 3.1),
the current system version, and the lowest developmental phase.
Other versions may be kept as comparison files; a tool will be
provided to re-create a complete version from the partial. When
a version becomes obsolete (e.g., unnecessary partial versions
and unsupported releases), it is discarded.
Multics Technical Bulletin MTB-739
System Dev. & Support Fac.
3.4 Problem Detection
There are many problems library tools can help detect,
particularly in software development phases. This early
detection may help reduce audit comments (and possibly failures)
and either remind or inform users of changes to the system they
did not know about (e.g., a piece of software has been
obsoleted). This is not meant to hold up all installations until
all problems are fixed, particularly in the development and
experimental phases of a module; it is meant to warn the user of
possible problems. Some of these are:
a) modules improperly called;
b) the use of obsolete (e.g., ios_) or discouraged (e.g.,
hcs_$initiate) objects;
c) control argument mis-usage in commands or user subsystem
requests;
d) calls to non-existant modules (via a dynamic
cross-reference);
e) modules registered in a bindfile, but not in the bind
archive (unless registered as freestanding), or the other
way around.
3.5 (Sub)System Building
SDSF should aid in the creation of commands and subsystems
with standard interfaces: argument processing, control argument
names and short-forms, error reporting, etc. However, it should
not enforce this with an iron fist as there are times when the
standard or registered interfaces do not suffice. For example,
users should be encouraged to use the registered command control
arguments, but if none of these fit the bill, then the user still
needs the control argument. By the same token, the standards and
registered interfaces should be kept as up-to-date as possible.
MTB-739 Multics Technical Bulletin
System Dev. & Support Fac.
4 EXISTING TOOLS
4.1 Installed Multics Commands
There are several installed Multics commands for library
installations and maintenance. These are update_seg,
get_library_segment, and the library_* commands (e.g.,
library_fetch). update_seg does a good job of doing the
installation, but many users have trouble using it with the
current interface. The library_* commands are also useful, but
most users do not seem to know them too well, sometimes causing
problems. The get_library_segment command, though supposedly
obsoleted by library_fetch, is still in active use since it
searches all the Multics libraries (which SDSF considers
subsystems of the Multics system library).
4.2 Multics/MCR Tools
The Multics Change Request (MCR) tools handle SCRs very
well, but is not installed in standard libraries. They also use
private software of an ex-MDC member which was deleted and had to
be recovered. These tools must be upgraded to interface with
SDSF; this is expected to mainly be in the form of additional
interfaces.
The Multics library (>udd>Multics>library) has many useful
tools which are used for debugging, development, regression
testing, structure cross-referencing, and auditing. The major
problem is that not everyone knows of these tools or the useful
features supported. As these tools are not installed, they do
not aid library users at other sites.
4.3 Subsystem exec_com's and Vector DBs
Lindsey Spratt and Matt Pierret developed a set of exec_coms
commonly referred to as the subsystem development (or subsys)
tools. They have proved very useful in Multics' Data Management
and B2 functional tests development. These are well thought out
tools and remove some of the hassles of update_seg from the
installer. Much of SDSF is based upon the subsys tools, and
lessons learned while working on them.
Multics Technical Bulletin MTB-739
System Dev. & Support Fac.
These tools have been growing incrementally during their
life. Some of the changes made do not fit will into the original
mechanism. One example is binding, which was added during the
Data Management project. It was relatively easy to add support
for bound modules, but some adjustments had to be made in module
handling which required database reloading. However, these tools
are very slow, due in large part to their being implemented as
exec_coms.
The subsystem tools use vector databases, a private DBMS,
which is relatively easy to use compared with many relational
database products. However, vector databases are easily damaged.
These tools are also written with exec_com, adding to their
slowness. The library database is difficult to expand to handle
large libraries, such as the entire Multics system library,
because it has a maximum size of one segment. This has caused a
few times reloading the subsys databases when the functionality
was expanded.
4.4 ACTC FORTRAN Maintenance exec_com's
The Advanced Computing Technology Center (ACTC) at Calgary
has developed several tools for their support of the FORTRAN
compiler. Of particular interest is the recreate.ec tool to
allow versioning to be handled easily. This was MCR'd at one
time, but changes were requested before allowing general
installation. A set of tools akin to this is required to support
multiple versions of modules, either between releases or for
backup capability.
5 OTHER SYSTEMS
There are several other systems in use on other systems.
The reader is referred to the References section for more
information on these systems.
Ada Programming Support Environment (APSE, KAPSE).
AT&T DMERT Software Control System
UNIX (TM) Source Code Control System (SCCS) and Revision
Control System (RCS)
Honeywell Software Development Environment (SDE, only runs
under UCOS III).
MTB-739 Multics Technical Bulletin
System Dev. & Support Fac.
6 INITIAL DESIGN
The following is the initial design to satisfy the minimum
initial requirement of being able to open modules for
modifications, and install them in the various phases necessary
for development, testing, and release. Auditing, binding, and
module building will be done early after the initial system is
operating as phase two of the SDSF project.
6.1 Databases
SDSF uses three databases: the per-system library
definition database, the per-library module and subsystem
definition database, and the subsystem module database. The
proposed data models for these databases are presented in their
own sections below. N.B.: all the defined relations will not be
used in the first implementation, but are included to aid in
understanding the SDSF mechanisms.
The databases will be implemented on Multics using MRDS with
Data Management (DM) files, not vfile_ files. While DM databases
are slower, they are also protected from process and system
failure. It is felt the SDSF interfaces usage will be small
compared to the entire work done to prepare a change to a library
and the small slow-down caused by using DM for reliability is
worth the cost.
6.1.1 PER-LIBRARY DEFINITION DATABASE
All subsystems and modules in a single library are defined
in the per-library definition database. All modules in a library
have a minimum of information which is required, in particular,
the subsystem the module belongs to, the version installed in the
system library, and the module's owner. Each subsystem is also
defined with various attributes. It also holds a small amount of
general information about the library, such as the current owner,
and historical information. See sdsf.library.cmdb for the data
model (Appendix A).
Multics Technical Bulletin MTB-739
System Dev. & Support Fac.
6.1.2 PER-SUBSYSTEM DATABASE
All modules' working information is kept in the subsystem
database. This includes the current state of a module's version
other than the system version, who is working on the module, and
the phase of the module (e.g., experimental). Provision has been
made to support the dynamic cross-referencer, binding
information, interface checking, auditing, and properties; these
are not planned for the initial implementation. See
sdsf.subsystem.cmdb (Appendix B).
It is important to remember the per-subsystem relations may
actually occur in the per-library database. This allows small
libraries, such as those owned by an individual users to require
only one database; at the same time, the system library is
allowed to have its component subsystems split away for quota and
access reasons.
A module name IS NOT necessarily unique within a library,
but IS unique within its containing subsystem. This requires us
to include the subsystem name in the primary key of the
per-library module relation and the per-subsystem module_state,
etc. relations.
6.2 Finding Libraries and Subsystems
There will be three ways for a user to find a library or
subsystem. Which mechanism is used will depend on how the
library is asked for when the library command is used.
A user process will normally have a default library set. If
a library is not explicitly requested, the default is used. If
the library specified is either an absolute or relative pathname
(i.e., contains either a ">" or "<" character), the library is
looked for at the given location.
If the library is specified only by a name, the library search
list is used to locate the library. The default library search
path is >site>libraries and it ideally contains links to all
publicly available libraries. As with forum meetings, it is
expected some users and projects will have their own paths to add
to the search list.
A process may also have a default subsystem set, but only for the
default library. In all other cases, the subsystem will either
need to be explicitly specified, or will be evident from the
module being worked with. If a module is not unique within a
library, the subsystem must always be explicitly set.
MTB-739 Multics Technical Bulletin
System Dev. & Support Fac.
6.3 Description of the library Command
A new command, library, will be added to the system. This
will implement the phase one SDSF requirements. It will replace
get_library_segment and library_fetch for those libraries which
use SDSF. The library install operation will either use
update_seg or its internals. Manual style documentation for the
library command can be found in Appendix C.
7 PROBLEMS
The major problem with the initial design is it is a very
small subset of the required functionality. It also does not
provide for multiple locks on the same module which is sometimes
necessary with large, multi-developer projects.
The install operation is still rather primitive. It is
difficult to save work when interrupted, such as when work must
be dropped for a meeting. One complaint of the subsys exec_com's
was the length of time to do an installation was very long. This
was in part due to the use of exec_com's for implementing subsys.
But the ability to have an absentee do (or at least do initial
preparation of) an installation was requested several times.
8 REFERENCES
The Ada Language System
by Martin I. Wolfe, Wayne Babich, Richard Simpson, Richard
Thall, and Larry Weissman, Computer, Vol. 14, No. 6, June
1981, pg. 37-45.
The Ada Environment: A Perspective
by Vic Stenning, Terry Froggat, Roger Gilbert, and Ellis
Thomas, Computer, Vol. 14, No. 6, June 1981, pg. 26-36.
The 3B20D Processor and DMERT Operating System: Software
Development System
by B. R. Rowland and R. J. Welsch, The Bell System Technical
Journal, Vol. 62, No. 1, Part 2, January 1983.
The 3B20D Processor and DMERT Operating System: Integration and
System Test
by W. F. Klinksiek and H. L. Mitchell, The Bell System
Technical Journal, Vol. 62, No. 1, Part 2, January 1983.
SDE I - Software Development Environment
by Mark D. Spinrad (Honeywell CSC), The Computer Sciences
Forum, Vol. 9, No. 2, April 1985.
Multics Technical Bulletin MTB-739
System Dev. & Support Fac.
Multics Library Maintenance SDN, Preliminary Edition
Order No. AN80, May 1979 (out of print).
MAB032-01: Experimental Library (EXL)
by Paul W. Benjamin, November 1982.
MAB056-02: Multics Configuration Management: Installing Planned
Changes in System Libraries
by Frank W. Martinson and Gary E. Johnson, August 1985.
MAB057-02: Multics Configuration Management: Installing
Emergency Changes in System Libraries
by Gary E. Johnson, August 1985.
MAB063-01: Multics Configuration Management: Critical Fixes for
Released Software
by Gary C. Dixon, August 1985.
MAB066: Multics Configuration Management: Software Development
by Benson I. Margulies and Ron Barstad, August 1985.
MAB067: Procedures for Software Installation and Integration
by W. Olin Sibert, August 1985.
MAB068: Multics Configuration Management: Programming Standards
by Ron Barstad, August 1985.
MAB069: Multics Configuration Management: Guidelines for
Auditing Software
by Gary C. Dixon, August 1985.
MAB070: Multics Configuration Management: Policy Statement
by Charles T. Clingen and Joe M. Stansbury, August 1985.
MAB071: Multics Security Coordinator: Duties and
Responsibilities
by Joe M. Stansbury, August 1985.
MTB416: New Program Coordination Facility
by David Spector, 14 May 1979.
MTB-739 Multics Technical Bulletin
System Dev. & Support Fac.
Appendix A - Per-library Data Model
/* ***********************************************************
* *
* Copyright, (C) Honeywell Information Systems Inc., 1986 *
* *
*********************************************************** */
/* DESCRIPTION
Data model for a SDSF library. All modules which are
to be handled by the system development and support
facilities (SDSF) must be registered in a library (and the
library must be registered in the SDSF system database).
This database plus all subsystem databases for the library
are equivalent to the subsys tools databases perm.vd,
location.perm.vd, and include_file.perm.vd.
ACCESS: r for all, rw for developers and SDSF
installers (unless the library is private).
A library maintainer may define subsystems within the
library. A subsystem may have a database separated from the
library database, though it is logically a part of the it.
This ability is provided to:
a) assign access of a specific subsystem to avoid
accidental damage,
b) distribute database storage through the hierarchy as
is done with the modules comprising the library, and
c) increase the speed of access to the database(s) of
very large libraries, as the Multics system library
or a site's local applications library.
The relations for a subsystem database should be
defined in this model. For clarity during the review
process, they are not and may be found in
sdsf.subsystem.cmdb. It is also expected a large library
will have a miscellaneous subsystem defined, which will use
the subsystem relations in the library database.
NOTE: a module_name is not unique within a library, but
is unique within a single subsystem.
*/
/* HISTORY COMMENTS:
1) change(86-01-23,Newcomb), approve (), audit ():
Initial prototype.
END HISTORY COMMENTS */
Multics Technical Bulletin MTB-739
System Dev. & Support Fac.
domain:
command char (256) varying aligned,
comment char (256) varying aligned,
location char (168) aligned,
name char (32) aligned,
time_created fixed bin (71)
; /* end domain definitions */
attribute:
command_dev command,
creation_approval name,
held_by name,
library_comment comment,
library_creation_approval name,
library_name name,
library_owner name,
library_state name,
library_time_created time_created,
module_name name,
module_type name,
owner name,
subsystem_name name,
subsystem_name_key name,
subsystem_state name,
version name
; /* end attribute declarations */
relation:
library_info ( /* general info */
library_name* /* only primary, e.g., rpi_chess,
but not chess and chs */
library_state /* e.g., development, experimental,
active (normal state), obsolete,
permanently_frozen (as rpi_chess is),
damaged */
library_owner /* "responsible" user, e.g., Roth.Mcc */
library_time_created /* history, e.g., 19771001 */
library_creation_approval /* history, e.g., Johnson.SysAdmin */
library_comment /* extra info, if desired */
),
subsystem_names (
subsystem_name* /* e.g., dms, data_mgt, and
data_management_system */
subsystem_name_key /* e.g., data_management_system */
),
subsystem (
subsystem_name_key* /* e.g., data_management */
location /* of subsystem's database,
e.g., >udd>m>dms_sys>dms.ssd */
subsystem_state /* see sdsf.system's library rel. */
owner /* "responsible user": used for
MTB-739 Multics Technical Bulletin
System Dev. & Support Fac.
problem routing, reporting,
charges, etc.; e.g., Data_Mgt */
time_created /* history */
creation_approval /* history (SCR or manager) */
held_by /* should only be a lib. maintainer;
if null, subsystem is free */
),
module (
module_name* /* e.g., before_journal_status */
subsystem_name_key* /* e.g., data_management again */
creation_approval /* SCR or manager */
owner /* user of primary responsibility */
version /* version in "system" hierarchy */
module_type /* lang., object, exec_com, etc. */
command /* if different from normal command;
for use with modules like as_who.pl1,
which will not compile with -tb */
),
compilation_command (
module_type* /* e.g., pl1, compose, alm */
command /* e.g., do "pl1 &r1 -ot -map &rf2" */
command_dev /* e.g., do "pl1 &r1 -tb -map -prefix..." */
); /* end of relation definitions */
index:
subsystem (owner subsystem_state held_by),
module (subsystem_name_key owner module_type)
; /* end of index definitions */
/* end of SDSF per-library definition data model */
Multics Technical Bulletin MTB-739
System Dev. & Support Fac.
Appendix B - Per-subsystem Data Model
/* ***********************************************************
* *
* Copyright, (C) Honeywell Information Systems Inc., 1986 *
* *
*********************************************************** */
/* DESCRIPTION
Data model for a SDSF subsystem library database. All
modules which are to be handled by the system development
and support facilities (SDSF) must be registered in this
database; in addition, they must also be registered in the
SDSF library database to which the subsystem belongs. See
sdsf.library.cmdb.
ACCESS: r for all, rw for all subsystem developers and
SDSF installers (unless the library is private).
*/
/* HISTORY COMMENTS:
1) change(86-01-23,Newcomb):
Initial prototype.
END HISTORY COMMENTS */
domain:
control_flag bit (1) aligned,
date_time fixed bin (71),
long_string char (256) varying aligned,
name char (32) aligned,
pathname char (168) aligned
;
/* end of domain definitions */
attribute:
access_list long_string,
add_name name,
auditor name,
audit_state name,
bound_module_name name,
called_entry_name name,
called_module_name name,
command long_string,
comment long_string,
date_audited date_time,
declaration long_string,
directory pathname,
directory_type name,
do_not_link_entries control_flag,
MTB-739 Multics Technical Bulletin
System Dev. & Support Fac.
entry_name name,
held_by name,
include_file_name name,
interface_type name,
location pathname,
module_name name,
module_state name,
no_link_entry name,
notification_type name,
old_module_name name,
old_version name,
phase name,
retain_entry name,
retain_all_entries control_flag,
retain_table_flag control_flag,
ring_brackets long_string, /* under investigation */
subsystem_name_key name,
time_phase_changed date_time,
time_state_changed date_time,
user name,
version name
;
/* end of attribute declarations */
relation:
directory_info (
directory_type* /* e.g., source */
subsystem_name_key* /* e.g., system_standard */
directory* /* e.g., >ldd>sss>s, >sss */
phase /* e.g., done, exl, dev */
),
module_state_info (
module_name* /* may only occur once per subsys */
subsystem_name_key*
held_by* /* who is currently working
on the module */
version* /* and what version is it? */
module_state /* open or shut */
time_state_changed /* history and metering */
phase /* see above */
time_phase_changed /* history and metering */
comment /* for user */
),
module_names ( /* used mainly for commands and exec_com's */
module_name*
add_name* /* also generates synonym statements if module
is bound in a larger executable unit */
subsystem_name_key*
),
notification ( /* for sending various notifications */
module_name* /* may be starname or name */
Multics Technical Bulletin MTB-739
System Dev. & Support Fac.
user* /* who wants to know? */
notification_type* /* always, or we can register a temp so
conflicting openings can be allowed */
subsystem_name_key*
),
interface ( /* for crossreferencing, depd, validation */
module_name* /* e.g., bjm_write */
entry_name* /* e.g., begin_mark */
version*
subsystem_name_key*
declaration /* entry (bit (36) aligned,...) */
interface_type /* internal, external, data */
),
external_dependency ( /* for crossreference, validation */
module_name*
version*
called_module_name*
called_entry_name*
subsystem_name_key*
),
include_file_dependency ( /* for crossreferene, validation */
module_name*
version*
include_file_name*
subsystem_name_key*
),
special_property (
module_name*
subsystem_name_key*
access_list /* used for privileged gates, etc. */
ring_brackets /* used for gates, etc. */
),
audit_info ( /* how did a module fare in audit? */
module_name*
version* /* what version was auditing */
subsystem_name_key*
phase /* what phase was audited */
auditor /* who did the audit? */
audit_state /* passed, failed, passed w/cmts, unaudited */
date_audited /* when was the last audit done? */
),
recreate_info ( /* how do we get back to an older version */
module_name*
version*
subsystem_name_key*
old_module_name* /* in case of renaming */
old_version
location /* of re-creation info */
command /* ... to to the transformation */
),
binding_info ( /* how do we package things? Used to
MTB-739 Multics Technical Bulletin
System Dev. & Support Fac.
create and/or validate bindfiles */
module_name* /* ...being bound */
subsystem_name_key*
bound_module_name /* container execution unit */
retain_table_flag /* yes ==> save symbol table; default
is to not retain it */
retain_all_entries /* yes ==> :global, else check the
binding_retain_info relation */
do_not_link_entries /* yes ==> :global, else check the
binding_no_link_info relation */
),
binding_retain_info ( /* entries to be retained */
module_name*
subsystem_name_key*
retain_entry*
),
binding_no_link_info ( /* entries to not be prelinked */
module_name*
subsystem_name_key*
no_link_entry*
);
/* end of relation definitions */
index: /* note: first component of a primary not indexed */
module_state_info (held_by version module_state phase),
notification (user notification_type),
include_file_dependency (include_file_name),
interface (entry_name version),
external_dependency (called_module_name called_entry_name
version),
audit_info (audit_state auditor),
binding_info (bound_module_name)
;
/* end of index definitions */
/* end of SDSF per-subsystem definition data model */
Multics Technical Bulletin MTB-739
System Dev. & Support Fac.
Appendix C - library Command Description
________________________________________
NAME: LIBRARY
SYNTAX AS A COMMAND
library operation args {-control_args}
SYNTAX AS AN ACTIVE FUNCTION
[library operation {-control_args}]
FUNCTION
The library command/AF is the interface to the System Development
and Support Facilities (SDSF). It allows a user to extract a
module (optionally locking against modification by others),
install one or more modules, release a module's lock, and do
various administrative functions.
ARGUMENTS
operation
designates the operation to be performed. See "List of
Operations" below for a description of each operation, its
command syntax line, and specific application.
CONTROL ARGUMENTS
can be one or more control arguments, depending on the
particular operation.
NOTES ON LOCKING
The locking of modules is used to aid productivity in a
multi-user environment. It is also possible to lock a library or
subsystem, but only for administrative purposes, except for the
one case of extra large installations. There is currently one
lock per module, with a per-version module lock being considered
for future implementation. A module's lock ID is the user's name
and project.
A module should only be locked if it is going to be deleted or
modified. Investigation is a normal start of the above two
activities; users should lock a module from the time
investigation of modifications start until the time the module is
installed or the investigation turns out negatively. In a
multi-user development/maintenance environment, it is possible
_______ _______
library library
_______ _______
for two people to start the same work without realizing it. When
a second user tries to lock a module already open to someone
else, he is informed of the other user's work via the lock
mechanism. This saves valuable time.
NOTES ON FINDING LIBRARIES
The user process normally has a current default library set and
it is this library which is searched. The user may use any
library he has access to via the -library control argument. If
-library's argument is a relative or absolute pathname (i.e.,
contains either a ">" or "<" character), the library must be at
the location specified. If the argument is a name, the library
search list is used to find the requested library.
LIST OF OPERATIONS
Each operation is described in the general format of a
command/active function. Where appropriate, notes and examples
are included for clarity.
Operation: cleanup
SYNTAX AS A COMMAND
library cleanup {NAMES} {-control_args}
FUNCTION
deletes library/subsystem modules no longer necessary. Library
modules matching one or more search name arguments are selected
as candidates for possible deletion. If their contents have not
been modified or used within a given grace period, then they are
eligible for deletion.
ARGUMENTS
NAMES
are the search names used to locate modules as candidates for
deletion. The Multics star convention can be used to identify
a group of modules with a single search name. Up to 30 search
names can be given in the command. (Default search name:
"!??????????????")
CONTROL ARGUMENTS
-brief, -bf
only lists modules eligible for deletion when a list was
requested. (Default)
_______ _______
library library
_______ _______
-date_time STR, -dt STR
causes a module to not be eligible for deletion if its
date/time contents modified and used are after the time
specified by STR. This control overrides the -time control.
(Default: the earlier of the current time minus seven days or
the system bootload time)
-delete, -dl
causes the modules that are eligible for deletion to be
deleted. (Default)
-library NAME, -lib NAME
specifies the library to be searched for modules to be
deleted. (Default: process' current default library)
-list, -ls
causes a list of the modules are eligible for deletion to be
printed on the user's terminal. (Default)
-long, -lg
causes the names of all modules matching the search names to
be printed on the user's terminal, even if they are not
eligible for deletion according to their date/time contents
modified/used. Modules that are eligible for deletion are
flagged with an asterisk (*). If -delete is used, only the
modules eligible for deletion are removed from the library.
-name NAME, -nm NAME
explicitly identifies a search name regardless of special
characters or whitespace in NAME (see NAMES above).
-no_delete, -ndl
indicates eligible modules are not to be deleted.
-no_list, -nls
does not create any listing of modules eligible for deletion.
-no_query
indicates the user is not to be queried for permission to
delete modules.
-query
asks the user for permission to delete modules before actually
doing so. (Default)
-subsystem NAME, -ss NAME
specifies the subsystem within the library to be searched for
modules to be deleted.
_______ _______
library library
_______ _______
-time days, -tm days
gives a grace period in days. Matching modules whose
date/time contents modified or used falls within this grace
period are not eligible for deletion. (Default: either seven
days, or the system bootload date minus the current date,
whichever is larger)
ACCESS REQUIRED
If an entry that is eligible for deletion resides in an inner
ring, library_cleanup must call the privileged
installation_tools_ gate to change its ring brackets prior to
deleting it. If the user does not have access to this gate, then
no cleanup is done and an error is reported.
Operation: create, cr
SYNTAX AS A COMMAND
library cr PATH {-control_args}
FUNCTION
creates a new library, prompting for information if necessary.
ARGUMENTS
PATH
the name of the library and the location where to put its
database.
CONTROL ARGUMENTS
-input_file PATH, -if PATH
causes the library setup information to be retrieved from the
file PATH. If not all the required information is found, the
user is prompted for what is missing, first being asked if the
request loop should be entered. See "Notes on create's input
file" below. This control overrides -request_loop.
-prompt
prompts the user for library creation information; overrides
-input_file. (Default)
-register
sends mail to the SDSF system administrator requesting a link
to the new library be put in the system-wide library search
directory, >site>libraries. It is recommended any library
meant for public consumption be linked to.
_______ _______
library library
_______ _______
-request_loop, -rql
enter the creation request loop; this control overrides
-input_file. (Default)
NOTES
The user creating the library is given administrative access to
the library. For existing libraries using Multics library
descriptors, it is recommended the descriptor source be used as a
starting point for creating the library creation information
file. No automatic conversion tools exist for going from a
library descriptor to an SDSF database as there are several
differences between the SDSF library/subsystem creation
information and a library descriptor.
NOTES ON CREATE'S INPUT FILE
A library creation file exists as a text file with a suffix of
"lib_cr" with a required syntax. The file is used to load the
library's and its subsystems' databases. There is a one-to-one
correspondence between the tuples to be loaded and the file
contents, except for some values provided by the creation
routines (e.g., time of library creation).
The lib_cr file has statements, values, and delimiters. The
statements are described below with sample values in the example.
A semi-colon (";") ends a statement. A colon (":") delimits a
keyword and its values. Commas are used to delimit values within
the same statement; whitespace is generally ignored unless the
value is quoted.
There are three major keywords for a lib_cr file: Library,
Subsystem, and Compilation. Only one Library statement may be
used. Any number of Subsystem and Compilation statements may be
given. There are various minor statements allowed for each major
statement and these correspond to various attributes of the
relations in the library and subsystem databases. They are shown
in the example below:
/* sample specification for library creation */
Library: Newcomb_lib, lan_lib; /* primary {, add} */
comment: string; /* used in system library registration DB */
Subsystem: public_tools, pub;
location: >udd>Multics>Newcomb>library /*>public_tools.db */
state: active;
owner: Newcomb.Multics;
approval: <none>; /* and none needed in this case */
directory_info: /* next stmts must be triplets */
_______ _______
library library
_______ _______
directory: >udd>Multics>Newcomb>library>source;
type: source;
phase: done;
directory: >udd>Multics>Newcomb>library;
type: executable;
phase: done;
directory: >udd>Multics>Newcomb>work;
type: source, executable;
phase: exl; /* No development dir */
Subsystem: private_tools, prvt;
location: >udd>Multics>Newcomb>library /*>public_tools.db */
state: active;
owner: Newcomb.Multics;
approval: <none>;
directory_info: /* next stmts must be triplets */
directory: >udd>Multics>Newcomb>library>private>source;
type: source;
phase: done;
directory: >udd>Multics>Newcomb>library; /* uses ACL's */
type: executable; /* to control access */
phase: done;
directory: >udd>Multics>Newcomb>work;
type: source, executable;
phase: exl; /* No development dir */
Compilation: /* minor stmts must be in triplets */
module_type: pl1;
command: "do ""pl1 &r1 -ot -map""";
command_dev: "do ""pl1 &r1 -tb -map -prefix size,stringrange
c,subscriptrange,stringsize"";
module_type: alm;
command: "do ""alm &r1 -list""";
command_dev: "do ""alm &r1 -list""";
/* end of example creation file */
It is possible to have a system default mechanism for the module
type specification for the Compilation statement. This is not
done to give the user more control over the library and what goes
in it by allowing evaluation of the new module type.
Operation: extract
SYNTAX AS A COMMAND
library extract MODULE {-control_args}
_______ _______
library library
_______ _______
SYNTAX AS AN ACTIVE FUNCTION
[library extract MODULE {-control_args}]
FUNCTION
extracts a module from a library into the user's working
directory, optionally locking the module against modification by
other users. The AF returns true if the module was extracted,
false otherwise.
ARGUMENTS
MODULE
is the name of the module to be fetched from the library.
CONTROL ARGUMENTS
-exists
indicates the module being copied from the library must
already exist. This overrides -new. (Default)
-extract
extracts the module, even when -lock USER_ID is specified.
(Default)
-force, -fc
extracts and locks the module, overriding another user's
existing lock. This requires administrative access to the
library/subsystem containing the module. A notification is
sent to the user whose lock is being bypassed.
-library NAME, -lib NAME
extract the module from the library named NAME instead of the
user's current default library.
-lock {USER_ID}
locks the module to the user when it is extracted. If USER_ID
is specified, it is used as the lock ID. If the lock ID is
not same as the current process' lock ID (requires
administrative access), a notification is sent to the user
being given the module's lock. If the module's lock cannot be
set, the operation is aborted. See "Notes on Locking" above.
(Default: -lock [user name].[user project])
-name MODULE, -nm MODULE
explicitly identifies MODULE as the name of a module to be
copied, regardless of special characters or whitespace; also
provided for abbrevs and self-documenting exec_coms.
_______ _______
library library
_______ _______
-new
only "extracts" the module if it does not already exist in the
library/subsystem. This may only be used with -lock.
-notify, -nt
registers the user for notification of when the module is
released from an existing lock. When the notification message
is sent, the registration is deleted.
-no_extract
do not copy the module from the library. This may only be
used when -lock is used. (Default with -lock when lock ID is
not current user's lock ID)
-no_force, -nfc
does not override another user's existing lock on the module
being copied. (Default)
-no_lock
indicates the module is not to be locked upon retrieval;
counteracts -lock. (Default)
-no_notify, -nnt
do not register the user for notification when the module is
released from an existing lock. (Default)
-no_template, -ntmp
do not create a template module when -new is given. (Default)
-subsystem NAME, -ss NAME
specifies the subsystem within the library the module is to be
extracted from. This is used to differentiate between modules
of the same name in a library (N.B., a module name is unique
within a subsystem, but not always within a library).
-template, -tmp
extracts a template module if -new was used and the module
type has a template defined for it; e.g., exec_com's, pl1, and
C type source modules may return a template source file. (Not
currently supported.)
-version STR
specifies which version of the module is to be extracted.
Currently, there is only one lock per module, not per module
per version. (Default: system installed version).
_______ _______
library library
_______ _______
NOTES
If the current lock ID is different from the default ID, a
warning is sent to the library administrator indicating normal
configuration management policies have been bypassed. Users who
lock modules should have the modules in the user hierarchy for
working them over, as the library copy is not supposed to be
directly modified. The case of locking a module in preparation
for deletion, though not a violation of CM policy, still causes
the warning message to be sent to the administrator.
Operation: install
SYNTAX AS A COMMAND
library install {MODULE} {-control_args}
FUNCTION
installs one or more modules into a library/subsystem, prompting
the user for needed information. Only developmental and
experimental installations are currently supported.
ARGUMENTS
MODULE
is one or more module names to be installed by addition or
modification. If not specified, all modules in the current
directory default to the installation set. The star
convention is allowed, as are relative and absolute pathnames.
CONTROL ARGUMENTS
-delete MODULE, -dl MODULE
specifies those modules to be installed via deletion from the
library/subsystem. The star convention is NOT allowed.
-library NAME, -lib NAME
specifies the library where the installation is to be done.
If not specified, the user's current default library is used.
-name MODULE, -nm MODULE
explicitly identifies MODULE as the name of a module to be
installed via addition or modification, regardless of special
characters or whitespace.
-subsystem NAME, -ss NAME
_______ _______
library library
_______ _______
specifies the subsystem within the library where installations
are to be done. If modules are to be installed in more than
one subsystem in one installation, this argument may be used
more than once, or not at all.
NOTES
Modules are installed according to the control information
recorded in the subsystem database containing the module.
Modules are installed at the newest level defined for the
subsystem. If a subsystem has a developmental level, the first
installation is done at that level. If the installation is being
done from the developmental level, then the next higher level is
used (e.g., experimental).
EXAMPLES
Data Management has three module levels defined: system,
experimental, and development. A modification is first installed
at the developmental level, then "promoted" to the experimental
level, and finally installed at the system level. The last step
is not currently supported in SDSF's first implementation phase.
Operation: lock
SYNTAX AS A COMMAND
library lock {-control_args}
SYNTAX AS AN ACTIVE FUNCTION
[library lock {-control_args}]
FUNCTION
locks an entire library or a library's subsystem so only the
locking user may access the library/subsystem. At least one
control argument specifying the object to be locked must be
given. A module may not be locked via this command; that may
only be done via the library extract operation. Other users may
hold locks to modules in the library/subsystem, but they will not
be able to access them.
CONTROL ARGUMENTS
-library NAME, -lib NAME
lock the library NAME, or find the subsystem to be locked in
the library NAME. NAME may be the name of the library as
registered in a library registration database, or an absolute
or relative pathname to the library.
_______ _______
library library
_______ _______
-subsystem NAME, -ss NAME
lock the subsystem NAME within a library.
Operation: notify, nt
SYNTAX AS A COMMAND
library nt MODULE {-control_args}
FUNCTION
registers the user for notification of when a new module version
is installed.
ARGUMENTS
MODULE
are one or more names of modules to be notified about. The
star convention is allowed to identify a group of modules with
an single name (e.g., lister*.*.**, **.ec, bjm*.*). The name
is stored as given, with no validation that any existing
modules in the library/subsystem match the name. This allows
the user to be notified when new modules are installed without
having to periodically update the notification registry.
CONTROL ARGUMENTS
-library NAME, -lib NAME
specifies the library to search when notifications are being
sent. If not used, the process' current default library is
used.
-name MODULE, -nm MODULE
explicitly identifies MODULE as the name of the module to be
notified about, regardless of special characters or
whitespace.
-remove, -rm
deletes existing notification registrations matching the given
specifications.
-set
registers the given modules for notification. (Default)
-subsystem NAME, -ss NAME
specifies the subsystem within the library to search for
modules when sending notifications.
_______ _______
library library
_______ _______
-to ADDR
indicates the notification mail is to be sent to ADDR; for
those who use several systems. (Default: [user name].[user
project])
NOTES
This notification registration is a "permanent" registration; it
is not removed after a notification is sent. Cf. with the
temporary notification registration which may be set by the
extract operation.
Operation: set_defaults, sdft
SYNTAX AS A COMMAND
library sdft -control_args
SYNTAX AS AN ACTIVE FUNCTION
[library sdft -control_args]
FUNCTION
sets or resets the per-process default library and/or subsystem.
CONTROL ARGUMENTS
-library NAME, -lib NAME
specifies the library to be the process' default library,
overriding any existing default.
-no_query
do not query for permission to override any existing defaults.
(Default)
-reset {STR}, -rs {STR}
clears out the process' default library and/or subsystem. If
STR is no given or is equal to "library" or "lib", the both
the process' default subsystem and library are cleared. If
STR is "subsystem" or "ss", the default library is not
changed, but the subsystem default is reset.
-query
asks the user for permission to change an existing default.
-subsystem NAME, -ss NAME
_______ _______
library library
_______ _______
sets the subsystem named NAME within the current default
library to be the process' default subsystem. A default
library must already be set, or be set by the current
invocation of this operation.
Operation: unlock
SYNTAX AS A COMMAND
library unlock {MODULE} {-control_args}
SYNTAX AS AN ACTIVE FUNCTION
[library unlock {MODULE} {-control_args}]
FUNCTION
unlocks a module, subsystem, or library, depending on the
arguments specified. The active function returns true if the
requested lock was released, false otherwise. At least one thing
to be unlocked must be given.
ARGUMENTS
MODULE
the name of the module to be unlocked. Normally, a module is
unlocked by the install operation.
CONTROL ARGUMENTS
-force, -fc
force the release of the specified lock, even if the user is
not the holder of the lock; this requires administrative
access to the library/subsystem, or SDSF administrative access
if a library is being unlocked. A notification is sent to the
user holding the lock informing him of the unusual action
taken.
-library NAME, -lib NAME
specifies library NAME is to be unlocked, or the subsystem or
module to be unlocked in library NAME. NAME may be the name
of the library as registered in a library registration
database, or an absolute or relative pathname to the library.
-name MODULE, -nm MODULE
explicitly identifies MODULE as the name of the module to be
unlocked, regardless of special characters or whitespace;
provided for abbrevs and self-documenting exec_coms.
_______ _______
library library
_______ _______
-no_force, -nfc
does not force the release of a lock if the user is not the
holder of the lock. (Defualt)
-subsystem NAME, -ss NAME
specifies subsystem NAME within the library is to be unlocked,
or the module to be unlocked is contained in subsystem NAME.