MULTICS TECHNICAL BULLETIN                                MTB-712

To:  MTB Distribution

From:  Richard A.  Holmstedt/Gary Johnson/F.  W.  Martinson

Date:  May 15, 1985

Subject:  Policy and Procedures for Software Integration.


This bulletin defines policies and procedures associated with the
installation  and  tracking  of  software  modifications  and the
distribution  of  a  Multics   release.   This  document  defines
policies and procedures required to  satisfy a B2 security rating
as it pertains to Configuration Management.

Refer to:

     MAB-052 Standards for Software Protection and STI.

     MAB-056   for  a   description  of   Procedures  for  Normal

     MAB-057  for  a  description  of  Procedures  for  Emergency

     MAB-063  for a  description of  Procedures for  Creating and
     Distributing Critical Fixes.

Requests  for  installation  of  software  must  conform  to  the
standards  documented  in  Procedures  for  Normal  Installations
(MAB056,  Revision  2),  Procedures  for  Emergency Installations
(MAB057),   or   Policies   and   Procedures   for  Creating  and
Distributing Critical  Fixes (MAB063).  All  software submissions
must  be  sent  to  the  System  Integration  Project  Leader, or
designate, who  reviews the submission to  insure conformity with
applicable   standards.   When   it  has   been  determined  that
applicable  standards  have  been  satisfied,  the  submission is
scheduled for  installation and passed to  the person responsible
for installation of software into System_M libraries.


Multics  Project  Internal  working  Documentation.   Not  to  be
reproduced or distributed outside of the Multics project.

MULTICS TECHNICAL BULLETIN                                MTB-712

A normal request for system change is made via the Multics System
Change  Request  (MSCR),  accompanied  with  an  approved Multics
Change Request (MCR).  Approval  for installation by the Software
Integration   Project   Leader,   or   designate,   will  include
verification  that  all  appropriate  signatures  of approval are
present.  The signature of the  Security Coordinator must also be
present if modifications involve the Trusted Computer Base (TCB).

Installation of software into System_M libraries, completed under
the standards  associated with MAB057 and MAB063,  do not require
formal Multics Change Request (MCR) approval and are tracked in a
lister database.   Developers are required  to submit an  MCR for
consideration within  30 days of software  installation under the
rules outlined in MAB057 or  MAB063.  An approved MCR will result
in removal of the installation  notice from the lister data base.
Failure to obtain  an approved MCR will result in  removal of the
associated software modification from  the system libraries prior
to  release  unless  such  software  is  retained  by  management

Software  intended for  distribution  to  customer sites  must be
submitted and  installed in the system libraries,  and be exposed
to  the user  community on  System_M.  This  system is physically
located in Phoenix, Arizona.


Installations  are  prepared  in  a  secure  directory  under the
>special_ldd hierarchy.  Access to  directories in this hierarchy
are limited as follows:

     sma   *.SysDaemon.*
     sma   *.SysMaint.*
     s     *.Multics.*
     s     *.SysAdmin.*
     null  *.*.*

The initial access for segments will be restricted to:

     rew   *.SysMaint.*
     r     *.Multics.*

Installations will be categorized  as online or hardcore.  Online
changes involve  software to be installed into  >sss, >tools, and
>unb.   Online  changes  are  prepared  under  the  sub-directory
>special_ldd>online.    The  directory   name  will   follow  the
convention    of    MCR_NUMBER-[date]    (i.e.,   6645-11/30/84).
Directories will have associated MCR numbers as add names.

Software included on the Multics System Tape, or software that is
part of the Multics Communications System, are prepared under the

MULTICS TECHNICAL BULLETIN                                MTB-712

sub-directory >special_ldd>hardcore.  The  primary directory name
for  the  installation  directory  will  be  the hardcore version
number, or the MCS version  number being prepared.  The directory
has add names for each associated MCR.

When  hardcore  and  online  changes  require  coordination,  the
version being prepared will be  the primary name of the directory
in both hierarchies:  For example:


In the  event a post bug  fix (PBF), or Multics  Emergency Change
Request  (MECR)  installation  is  received,  the  procedures  as
outlined in MAB-056 and MAB-057 will be followed.  The processing
of a PBF or MECR will be  the same as a normal installation.  The
major  exception will  be the  lack of  a Multics  Change Request
(MCR)  form.  This doesn't  represent a problem  to configuration
management as  the MCR for any  MECR is to be  submitted within 2
working weeks of installation as documented in MAB-057.  The MECR
installation will be tracked in  the MECR tracking database until
the MCR is approved and a standard MSCR is submitted.

The MCR for  the PBF will remain with the  original system change
request form.

The only  difference in preparation  will occur in  the directory
name convention for online changes.

     1) For  MECR type installations the directory  will be named
     for the MECR tracking number, i.e.  P0100.

     2) For  PBF type installations, the directory  will be named
     MCR_NUMBER.pbf.   Where   the  MCR_NUMBER  will   provide  a
     historical reference to the original change.

When the MECR or PBF applies  to hardcore, then the MCR number to
which  the PBF  applies, or  the  MECR  number will  be noted  in  All paperwork assoiated with this type of
change will then be processed as any other normal installation.

Preparation  of  software  installations  involves  several steps
which  must be  individually completed  without error  or warning
messages.  These steps are:

 1)  Use the  copy command to place all  modified source modules,
     include files,  and bindfiles into the  installation working

 2)  List the contents of  the installation working directory and

MULTICS TECHNICAL BULLETIN                                MTB-712

     manually  compare  against  the  MSCR  to  insure  that  all
     required segments have been copied.

 3)  At this  point, the manual  check to assure  all the modules
     are present, has been  done.  The installation will continue
     with   the   prepare_installation   (pinst)   absentee  (see
     "Appendix A" for an example of the absentee).  The following
     steps are the procedures followed in the absentee process:

     a) Complete a  compare_ascii (cpa) on all  source modules in
        the installation working directory.

     b) A  peruse_crossreference  (pcref)  of  all  include files
        associated  with the  installation is  done.  Any  source
        module  using the  modified  include  file, which  is not
        already present, is copied from the system libraries.

     c) Delete all segments  in >special_ldd>audit>CPA which have
        not been modified within the previous thirty (30) days.

     d) A compare of  the submitted module will be  made with the
        module  installed in  the library.   The output  from the
        compare  will be  placed into  the >special_ldd>audit>CPA
        directory with the naming convention of

        When  a segment  with this  name already  exists in  this
        directory, that indicates the  module was part of another
        installation  that has  taken  place  within the  last 30
        days.  The  output from the compare will  be printed, for
        review  by the  installer,  to  insure that  the previous
        installation is not being backed out.  When it appears to
        the  installer  that  a  previous  installation  is being
        backed out, the developer(s) involved will be notified so
        that corrective action can be taken.

     e) Create a directory  under >special_ldd>audit>CPA with the
        name of  the installation working directory,  and place a
        copy of  the compare output into  that directory.  (NOTE:
        The  directories under >special_ldd>audit>CPA  are dumped
        onto magnetic tape  at the time of a  Multics Release, or
        when quota restrictions require.)

     f) Check each  module in the installation  working directory
        using  the  display_pnotice   command  to  insure  proper
        copyright protection.

     g) Check   each  module   for  inclusion   of  proper   self
        documenting error documentation.

     h) Compile  each source   module with  appropriate compiler,
        using  appropriate   options  (e.g.,  PL1   programs  are
        compiled  using -optimize and  -map to generate  the most

MULTICS TECHNICAL BULLETIN                                MTB-712

        efficient  code  and  to  create  a  .list segment).  All
        modules must compile without error or warning messages.

After the steps outlined  above have been successfully completed,
the source  and object archives associated  with the installation
are  copied  into  the  installation  working  directory from the
installed system libraries.  These archives are then updated with
the new modules.

After   being  updated,  the   archives  are  sorted   using  the
archive_sort command.

All  object  archives  are  then  bound  using  the bind command.
Binding must occur without error or warning.

Only after all these steps  have been successfully completed, are
changes  ready for  installation into  the system  libraries.  To
complete the installation, the create_update_seg (cus) command is
used  to generate  an   The cus  command searches  the
system library  and marks new modules as  'replacements'.  When a
library  module  with  a  name  matching  a  new module cannot be
located,  the  installer  is  prompted  to  supply an appropriate
library pathname.

Following the  successful creation of an, that segment
is manually edited  to provide a description of  the change being
installed.     This    description    is    placed    into    the   or   segments  which
reside in the >documentation>iml_info_segments directory.

This  is done  by means  of links  in the  installation directory
which lead  to system segments used by  the installation process.
When update_seg  is used to perform the  actual installation, the
command  will  require  links  to  special  installation specific

  o  Installations.log  is  an  ascii  segment  used  to document
     installation  information including  all modules  installed.
     Information is  automatically added when update_seg  is used
     with the -log argument.

  o  Installations.lock  prevents   separate  installations  from
     being simultaneously performed by gating installations.

  o is a standard  info file which contains a
     reverse  chronological history  of library  changes made  by
     update_seg.   The  link  points  to  a  changes  segment  in

At this point the installation is ready and can be installed with
the update_seg  command.  The  is run and  monitored by
the installer  to assure no  errors exists.  A  typical

MULTICS TECHNICAL BULLETIN                                MTB-712

might appear as follows:

us in [time] -log
MCR  6885 and 6920: Installed bound_mseg_ (Standard).  Changed
the  message  segment primitive to store the complete process
authorization,  including the privileges, with each message in
the  segment.  Also, fixed all reported problems in the ring-1
message segment.
us rp bound_mseg_.s.archive >ldd>sss>s>== -ac -rb 1 5 5 -acl r *
us rp bound_mseg_.archive >ldd>sss>o>== -ac -rb 1 5 5 -acl r *
us rp mbx_mseg_.list >ldd>listings>sss>== -rb 1 5 5 -acl r *
us rp mseg_.list >ldd>listings>sss>== -rb 1 5 5 -acl r *
us rp mseg_add_.list >ldd>listings>sss>== -rb 1 5 5 -acl r *
us rp mseg_create_.list >ldd>listings>sss>== -rb 1 5 5 -acl r *
us rp mseg_util_.list >ldd>listings>sss>== -rb 1 5 5 -acl r *
us rp queue_mseg_.list >ldd>listings>sss>== -rb 1 5 5 -acl r *
us rp bound_mseg_ >sss>== -log -ss

When   the  exec_com   is  executed,   an  installation  segment,
[time].io, is created.  If no errors are detected the "update_seg
install" command is executed.

This  command   will  physically  move  the   segments  into  the
appropriate                   libraries,                   update
>documentation>aml>,         and        update
>ldd>Installations.log.  The Installations.log entry would appear
as follows:

MCR 6885 and 6920:  Installed bound_mseg_ (Standard).  Changed
the message segment primitive to store the complete process
authorization, including the privileges, with each message in
the segment.  Also, fixed all reported problems in the ring-1
message segment.

12/05/84  1135.7    bound_mseg_ replaced in SSS

       replaced:    mseg_

The  developer  will  be  informed  by  electronic  mail that the
installation has been completed.

The  MSCR form,  along with  the  MCR,  will then  be filed  in a

MULTICS TECHNICAL BULLETIN                                MTB-712

cabinet, in  chronological order and kept  for permanent history.
It will  be the responsibility of the  System Integration Project
leader  to keep this  file, on site,  at the Multics  development
center in Phoenix, Arizona.

Under  this procedure,  to track   all changes  to a  module, the
Installations.log can  be scanned for an  individual module.  The
history of the  MCR will be documented in the  log along with the

When  the MCR is  known the audit  directory can be  retrieved to
examine the compare output segments.   Knowing the MCR number and
date will point to the physical installation forms which can then
be located and pulled from the file.

The backup tapes from the  installation system in Phoenix will be
kept  for  one   year  to  make  it  possible   to  retrieve  the
installation  and  the  library  module  in  question.  The audit
directories will be available on the tape saves.  The audit tapes
will be kept in the System M tape library.

In  summary, the  relevant documentation  that each  installation
creates is:

     a) >ldd>Installations.log  This is  a total  history of  all
        installations  for a  complete release.   The information
        contained   within  the   log  are   dates,  summary   of
        installation,   bound   units   installed,   and  modules
        replaced, added, or deleted.

     b) >special_ldd>audit>CPA>{Installation   Directory},  where
        Installation   Directory   follows   the   convention  of
        MCR_NUMBER-[date]  (i.e.,  6645-11/30/84).   Within  this
        directory will  be found all compare ascii  output of the
        changes made with a given installation.

     c) >documentation>aml>,  this contains  a
        brief  description  of  the  the  changes  made to online
        software,   the  MCR   number,  and   bound  units  being
        installed.   This information  can also  be found  in the
        Installations.log for the release.

     d) >documentation>aml>, this contains a
        brief  description  of  the   changes  made  to  hardcore
        software,  the hardcore  version identifier,  and the MCR
        number for the changes being installed.

     e) Multics  System Change  Request (MSCR),  is the  hardcopy
        forms submitted by the developer.  This document contains
        all  information for  each system  change.  The documents

MULTICS TECHNICAL BULLETIN                                MTB-712

        are  filled  by  date   once  an  installation  has  been
        completed.   The MSCR is  retained for two  major Multics

With this information, anyone  needing detailed information on an
installation or module could  start with the Installation.log and
an editor.

By doing  a string search on  the module name it  will be quickly
determined if the  module has been modified, and  when.  Once the
date has been  determined, the MSCR for that  installation can be
pulled.   This  will  provide   detailed  information  about  the
installation, which  can be verified with the  information in the

If  the compare  output for  the module  in question  needs to be
examined, the  directory >special_ldd>audit>CPA>{MCR_NUMBER.DATE}
can be located.  This directory  will contain all the information
as outlined above.

The Multics Release

The  Software Integration  project  will  be responsible  for the
generation  and  publication  of  the  Multics  Software  Release
Bulletin   and   the   Multics   Software   Release  Installation

The Software Release Bulletin (SRB) is a composite of information
provided  by the  developer, which  is included  on the  MCR form
submitted with  the installation.  The  Installation Instructions
are generated  from information provided by  the developer, which
requires  intervention by the  site personnel to  allow continued
correct operation of the system.

After a reasonable freeze and exposure period, the Master Multics
Release tapes  are dumped from the Multics  development system in
Phoenix.   As part  of the  release preparation,  a directory  is
created  in >documentation>MRXX  where  XX  is the  major release
indicator.   Within this directory,  and shipped to  the customer
site will be the SRB, SIB and error message documentation.

The release includes a set of magnetic tapes, hardcopy dump maps,
and accompanying documentation.

For each release, a set of master tapes is generated and all dump
maps reflect the contents of  these master tapes.  All tapes sent
to  the  field  are  copies  of  the  master  tapes.   Because of
different  lengths of magnetic  tape reels, there  may not be  an
exact correlation between a single tape and a dump map.

MULTICS TECHNICAL BULLETIN                                MTB-712

Site personnel may assure themselves of the contents of the tapes
by visually matching the maps produced from the reload operations
against the master dump maps supplied.

Tapes  are verified  using  the  following approach.   The Master
Development  tapes are  copied onto  a Customer  Service Division
Master  tape set  for copy  and distribution  to the  field.  The
development   tapes  are   compared   to   the  CSD   tapes  with
copy_dump_tape command.  Each set of  tapes sent to the field are
generated from the master set, then verified for correctness.

The  master release tapes  are further verified  by testing on  a
Multics system where the instructions for installing a system for
the  first time  will be   executed.  The  system is  booted from
scratch.   The  system  then  tested  with  the  development test
scripts   and  the   Configuration  Management   Functional  Test

A system running the most recent  prior release is also tested by
updating it to  the current release.  The test  scripts are again
run to assure error free operation.

MULTICS TECHNICAL BULLETIN                                MTB-712

                            APPENDIX A


The following is an abbreviated example of how an installation is
checked       and      prepared      with       the      absentee

Some command lines  in this example have been folded  over due to
line length consideration.  All folded lines will be continued on
the following line indented by two spaces.


&command_line off

&if [nless &n 1] &then &goto USAGE
&if [not [exists dir &1]] &then &goto NODIR
cwd &1
&goto &ec_name
&label pinst
& da ** -a -bf
sa ** rw *.SysMaint r *.Multics

date_deleter >spec>temp>CPA 30 **.cpa

do "if [exists seg >spec>temp>CPA>[before [string &(1)] .pl1].cpa]
 -then ""eor -rqt pmdc_l6 -q 3 -he Holmstedt -ds == -dupt
 >spec>temp>CPA>[before [string &(1)] .pl1].cpa"""([segs *.pl1])

do "fo >spec>temp>CPA>[before [string &(1)] .pl1].cpa -tc;gls &(1)
  -rename;cpa &(1) -he;dl;ro"([segs *.pl1])

&if [not [exists dir >spec>temp>CPA>[st -wd -primary]]] &then
  cd >spec>temp>CPA>[st -wd -primary]

sis >spec>temp>CPA>[st -wd -primary] r *.Multics r *.SysMaint null *

do "answer yes -bf cp  >spec>temp>CPA>[before [string &(1)] .pl1].cpa
  >spec>temp>CPA>[st -wd -primary]>=="  ([segs *.pl1])

display_pnotice ([segs *.pl1])

extract_message_doc ([segs *.*]) [pd]>junk1

& if >spec>on goto ON, if not >spec>on goto HARD

&if [equal [index &1 >on] 0] &then &goto HARD

&label ON
do "if [exists segment >ldd>incl>&(1)] -then ""answer no -bf
  lf [pcref &(1)] -lb sss.s""" ([segs *.incl.*])

do "if [exists segment >ldd>incl>&(1)] -then ""answer no -bf
  lf [pcref &(1)] -lb unb.s""" ([segs *.incl.*])

do "if [exists segment >ldd>incl>&(1)] -then ""answer no -bf
  lf [pcref &(1)] -lb t.s""" ([segs *.incl.*])

rdc ([segs *.rd])
pl1_macro ([segs **.pmac])
new_fortran ([segs *.fortran]) -ansi77 -round -ot -map
do "ioa_ ""assembling &(1) "";cds &(1) -list" ([segs *.cds])
do "ioa_ ""assembling &(1) "";alm &(1) -list" ([segs *.alm])
do "ioa_ ""compiling &(1) "";pl1 &(1) -ot -map" ([segs *.pl1])

&label LISP
do "ioa_ ""compiling &(1)"";lcp &(1) -list" ([segs *.lisp])

&label HARD
do "if [exists segment >ldd>incl>&(1)] -then ""answer no -bf
  lf [pcref &(1)] -lb h.s""" ([segs *.incl.*])

rdc ([segs *.rd])
pl1_macro ([segs **.pmac]) -target """bce"""
do "ioa_ ""assembling &(1) "";cds &(1) -list" ([segs *.cds])
do "ioa_ ""assembling &(1) "";alm &(1) -list" ([segs *.alm])
do "ioa_ ""compiling &(1) "";pl1 &(1) -ot -list" ([segs *.pl1])

&label USAGE
sm [user name].sm pinst needs argument.
&label NODIR
&print Bad path name given: &1