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.
INTRODUCTION
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
Installations.
MAB-057 for a description of Procedures for Emergency
Installation.
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
directive.
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.
PREPARATION OF INSTALLATIONS
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:
>special_ldd>hardcore>41-0
>special_ldd>online>41-0
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
hardcore.changes.info. 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
directory.
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 SOURCE_NAME.cpa.
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 update.ec. 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 update.ec, that segment
is manually edited to provide a description of the change being
installed. This description is placed into the
online_changes.info or hardcore_changes.info 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
segments:
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 Installations.info 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
>documentation>aml>online.changes.info.
At this point the installation is ready and can be installed with
the update_seg command. The update.ec is run and monitored by
the installer to assure no errors exists. A typical update.ec
MULTICS TECHNICAL BULLETIN MTB-712
might appear as follows:
&attach
us in [time] -log
Input:
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.
.
&detach
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>online.changes.info, 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_
mseg_add_
mseg_util_
mseg_create_
mbx_mseg_
queue_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
date.
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>online_changes.info, 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>hardcore_changes.info, 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
Releases.
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
Installations.log.
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
Instructions.
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
software.
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
PREPARE INSTALLATION ABSENTEE
The following is an abbreviated example of how an installation is
checked and prepared with the absentee
prepare_installation.absin.
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.
PINST.ABSIN
&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 foo.bar;cpa foo.bar &(1) -he;dl foo.bar;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])
&quit
&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])
&quit
&label USAGE
sm [user name].sm pinst needs argument.
&quit
&label NODIR
&print Bad path name given: &1
&quit