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


       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



                 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)


                 Appendix C - library Command
                  Description . . . . . . . . . . . . .    21
                    library . . . . . . . . . . . . . .    21

  System Dev. & Support Fac.


       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

       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.


       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.


       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.


       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

  Multics Technical Bulletin                                MTB-739
  System Dev. & Support Fac.


       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.


       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.


       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    (*
  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).


       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.,

       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

       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.


       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.


       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
    d) calls    to   non-existant     modules   (via    a   dynamic
    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.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

       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

       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  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.


       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.


       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.


       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.


       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.


       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.


  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
       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 *
     *                                                         *
     *********************************************************** */


            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.

    1) change(86-01-23,Newcomb), approve (), audit ():
       Initial prototype.
                                            END HISTORY COMMENTS */

  Multics Technical Bulletin                                MTB-739
  System Dev. & Support Fac.

       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 */

       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 */

    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 */

       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 *
     *                                                         *
     *********************************************************** */


            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

            ACCESS:  r for all, rw for all subsystem developers and
       SDSF installers (unless the library is private).


    1) change(86-01-23,Newcomb):
       Initial prototype.
                                            END HISTORY COMMENTS */

       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 */

       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 */

    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 */
       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 */
       add_name*      /* also generates synonym statements if module
                         is bound in a larger executable unit */
    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 */
    interface (       /* for crossreferencing, depd, validation */
       module_name*   /* e.g., bjm_write */
       entry_name*    /* e.g., begin_mark */
       declaration    /* entry (bit (36) aligned,...) */
       interface_type /* internal, external, data */
    external_dependency (       /* for crossreference, validation */
    include_file_dependency (   /* for crossreferene, validation */
    special_property (
       access_list    /* used for privileged gates, etc. */
       ring_brackets  /* used for gates, etc. */
    audit_info (      /* how did a module fare in audit? */
       version*       /* what version was auditing */
       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 */
       old_module_name*         /* in case of renaming */
       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 */
       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 */
    binding_no_link_info (      /* entries to not be prelinked */
  /* 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
       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




  library operation args {-control_args}


  [library operation {-control_args}]


  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.


     designates  the  operation  to  be  performed.   See  "List of
     Operations"  below for  a description  of each  operation, its
     command syntax line, and specific application.

     can  be  one  or  more  control  arguments,  depending  on the
     particular operation.


  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.


  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.


  Each  operation   is  described  in  the  general   format  of  a
  command/active function.   Where appropriate, notes  and examples
  are included for clarity.

  Operation:  cleanup


  library cleanup {NAMES} {-control_args}


  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.


     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:


  -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.

     indicates  the user  is not  to be  queried for  permission to
     delete modules.

     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)


  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


  library cr PATH {-control_args}


  creates a new library, prompting for information if necessary.


     the  name of  the library  and the  location where  to put its


  -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.

     prompts the  user for library creation  information; overrides
     -input_file.  (Default)

     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)


  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.


  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
    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


  library extract MODULE {-control_args}

  _______                                                   _______

  library                                                   library
  _______                                                   _______


  [library extract MODULE {-control_args}]


  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.


     is the name of the module to be fetched from the library.


     indicates  the  module  being  copied  from  the  library must
     already exist.  This overrides -new.  (Default)

     extracts  the module,  even when  -lock USER_ID  is specified.

  -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
  _______                                                   _______

     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.

     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)

     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
  _______                                                   _______


  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


  library install {MODULE} {-control_args}


  installs one or more  modules into a library/subsystem, prompting
  the  user   for  needed  information.   Only   developmental  and
  experimental installations are currently supported.


     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.


  -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.


  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).

  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


  library lock {-control_args}


  [library lock {-control_args}]


  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.


  -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


  library nt MODULE {-control_args}


  registers the user for notification  of when a new module version
  is installed.


     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.


  -library NAME, -lib NAME
     specifies the  library to search when  notifications are being
     sent.  If  not used, the  process' current default  library is

  -name MODULE, -nm MODULE
     explicitly identifies MODULE  as the name of the  module to be
     notified   about,   regardless   of   special   characters  or

  -remove, -rm
     deletes existing notification registrations matching the given

     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


  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


  library sdft -control_args


  [library sdft -control_args]


  sets or resets the per-process default library and/or subsystem.


  -library NAME, -lib NAME
     specifies  the library  to  be  the process'  default library,
     overriding any existing default.

     do not query for permission to override any existing defaults.

  -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.

     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


  library unlock {MODULE} {-control_args}


  [library unlock {MODULE} {-control_args}]


  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.


     the name of the module to  be unlocked.  Normally, a module is
     unlocked by the install operation.


  -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

  -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.