MULTICS TECHNICAL BULLETIN MTB-640
To: MTB Distribution
From: Chris Jones
Date: 28 November 1983
Subject: Reconfiguration Extended
This MTB describes plans for enhancements to the reconfiguration
software of Multics. It is proposed that logical channels, MPCs,
IOMs, and FNPs be dynamically reconfigurable much as CPUs, SCUs,
and page frames are today.
These extensions will make it truly possible to split a Multics
system into two or more independent systems while it is running.
The increased flexibility will make it easier to perform off-line
testing of doubtful hardware without system interruption.
Comments and questions should be sent to the author:
by US mail
Christopher L. Jones
Honeywell / CISL
4 Cambridge Center
Cambridge MA 02142
by telephone
(617) 492-9330 or HVN 261-9330
by Multics mail
CLJones.Multics on System M or MIT-Multics
_________________________________________________________________
Multics Project internal working documentation. Not to be
Page 2 MTB-640
1 INTRODUCTION
Current Multics reconfiguration software allows page frames,
SCUs, some devices (tapes and disks), and CPUs to be dynamically
added and deleted from the system configuration. It is not
currently possible to do the same with certain other devices,
MPCs, FNPs, logical channels, or IOMs.
Many customers have requested the ability to dynamically
reconfigure IOMs. It was identified as a desirable function for
MR10 by the MR10 Design Review Board. Funding for this project
has been provided through an RPQ from HIS Canada for the Canadian
Department of National Defence. The project is now underway and
is scheduled for completion in mid-1984.
2 GENERAL PHILOSOPHY
The reconfigurable entities that we are concerned with are
enumerated below. This list is a more or less hierarchical
ranking; in general an item is directly connected to the items
above and below it in the list.
Reconfigurable Entities
- Devices (FNPs, Unit Record Devices, Operator Consoles,
Special Devices)
- MPCs
- Logical Channels
- IOMs
The basic policy to be followed is this: No item can be deleted
from the configuration if it is part of the only path to another
undeleted item. This means, for example, that a disk channel
could not be deconfigured if it were the only channel which could
communicate with a disk which was still configured. If the disk
were deconfigured first, however, the channel could then be
deleted. Conversely, no item can be added which does not have a
path to it. Thus, an MPC cannot be added if the only IOM it is
connected to is deleted.
In addition, there will be a few other constraints. Just as the
last CPU cannot be deleted, the last operator's console cannot be
deleted. Disks, channels, and MPCs, etc. needed for system
operation will not be able to be deleted.
Since each of the reconfigurable entities mentioned above has
some unique characteristics, each will be discussed separately.
In addition, there is some work which has to be done which falls
MTB-640 Page 3
3 MISCELLANEOUS TASKS
In order to allow the maximum flexibility when splitting a system
into several independent systems, the following tasks will be
done as part of this project:
- a command will be provided to move all of the process
directories from one logical volume to other logical
volumes
- it will be possible to boot the system from IOMs other
than IOM a
- to allow for recovery from a system crash when there is
no configured operator's console, it will be possible
Page 4 MTB-640
4 RECONFIGURATION OF DEVICES
4.1 General
Multics already allows disk and tape units be be added and
deleted. In order to support full reconfiguration, it will be
necessary to add reconfiguration support for the other device
types. The types of devices for which support must be added
include
- unit record devices (printers, card readers, punches)
- operator consoles
- FNPs
- special devices
RCP manages these devices for the most part (FNPs are a notable
exception). There are already deldev and adddev initializer
commands which currently handle only tape and disk units. The
RCP reconfiguration software would have to be extended to manage
the other devices as well. Unit record devices and special
devices present no obvious problems when it comes to adding this
support.
4.2 Operator Consoles
Effective in MR10.2 operator console output can be assigned to
any configured operator's console by using the set_system_console
command. It is even possible to run with no operator's console
enabled at all. Thus, it becomes trivial to extend
reconfiguration to consoles. The only restriction is that you
cannot delete the current operator's console.
4.3 FNPs
FNPs are a special case. FNP reconfiguration is already in
place. FNPs can be made active and inactive dynamically. The
active state corresponds to the "on" state (of a CPU, for
example), while inactive corresponds to the "off" state. The
current state of an FNP is maintained in the CDT (Channel
Definition Table). As part of extending reconfiguration, we will
make the fnp card of the config deck include the current state of
the FNP. We also will change the FNP reconfiguration commands to
communicate this information to IOI, which has become the
maintainer of the central database for I/O reconfiguration. IOI
needs this information to allow it to decide when an IOM can be
deleted (among other things, the FNPs connected to that IOM must
MTB-640 Page 5
FNPs currently employ only one physical channel as their
connection to the IOM. This physical channel is addressed as one
logical channel. In order to deconfigure this logical channel,
we would require that the FNP must first be made inactive. Some
FNPs have available a SECOND physical channel. Some thought
should be given as to how to dynamically switch from one physical
channel to the other. This is a complicated problem, involving
synchronization between the FNP resident programs and the
hardcore. For this reason, I propose that this problem be
deferred until later.
Note: Some future DIAs may support more than one logical
channel per physical channel. It will take some
changes to the FNP software to be able to support
this feature. When this is done, there will also
be a problem with deconfiguring a logical channel
connected to an FNP, as the FNP must be made aware
that the channel is not available. This whole
Page 6 MTB-640
5 LOGICAL CHANNEL RECONFIGURATION
5.1 General
While not inherently difficult, dynamic reconfiguration of
logical channels is complicated by the variety of modules which
manage them. Logical channels can be under the control of ioi_,
disk_control, ocdcm_, or FNPs. The io_manager interface will be
extended to include adding and deleting channels, and IOI will be
the caller of these entries. It is not necessary to consider the
non-IOI devices since these devices have only one channel, and in
order to delete the channel, the device would have had to have
been deleted first. IOI will usurp channels from disk_control
when disk channels are deleted, and will cede them to disk
control when they are added.
5.2 Deleting Logical Channels
In order to delete a logical channel, the channel must not be in
use. Also, it may not be the only logical channel which can
reach an as yet undeleted device. If it is, an appropriate error
code is returned. The other check which is performed is to
ensure that the base logical channel of a physical channel is not
deleted if the other logical channels on that physical channel
have not all been deleted. This is done because certain special
interrupts always interrupt on the base logical channel, and
deleting this channel would make Multics unable to process these
interrupts.
Assuming that the channel is able to be deleted, it is marked as
deleted in the iom_data database. Calls to io_manager$assign
will return an error code indicating that the logical channel has
been deleted.
5.3 Adding Logical Channels
Adding logical channels is a straightforward operation. The
MTB-640 Page 7
6 RECONFIGURATION OF MPCS
6.1 General
MPCs (Microprogrammed Peripheral Controllers) interface on one
side to peripheral devices, and on the other side to logical
channels (and hence, the IOM). One MPC may be connected to more
than one IOM, which somewhat complicates the job of reconfiguring
them. The general philosopy remains the same: an MPC may not be
deleted if it is part of the only available path to an undeleted
device. For example, in the figure below (from the configuration
of a large Multics site in the American southwest), if any of the
disk drives making up subsystem dskc are not deleted, then either
mspc or mspd may be deleted, but not both.
+-------+ +-------+
| | | |
| iom a | +------+ +------+ | iom b |
| |====| | | |====| |
+-------+ | mspc | +------+ | mspd | +-------+
| |====| |====| |
+------+ | dskc | +------+
| |
+------+
Figure 1. Sample MPC configuration
When adding an MPC, it may be advisable to reload the firmware of
the MPC. The routines which add an MPC could allow this as an
option. In the future, we should probably add an mpcs (MPC
state) card which tells whether the MPC is on or off, and what
firmware is loaded in it. This would allow us to boot a system
with a given system in the off state, and add it later, much as
can be done with memory and CPUs today.
Other than firmware considerations, adding and deleting an MPC
consists of adding and deleting the channels associated with it.
In fact, there will be no ring 0 support for explicitly adding or
deleting an MPC. The commands will simply add or delete the
Page 8 MTB-640
7 IOM RECONFIGURATION
7.1 Deleting IOMs
In order to delete an IOM, all logical channels connected to it
must have been previously deleted. This can be accomplished in
one of two ways: the channels may be deleted by explicit calls
(see "Logical Channel Reconfiguration" earlier in this paper), or
the user may specify that all necessary deconfiguration to effect
the deletion of the IOM should be performed. If for any reason
some part of this deconfiguration should fail, the effect will be
as if the call had not been issued: nothing will have been
deconfigured.
7.2 Adding IOMs
To add an IOM to the configuration, it must of course appear in
the config deck. In addition, several consistency checks will be
made in an attempt to ensure that adding this IOM will not
compromise the integrity of the system. It appears impossible to
check all of the switch settings on the IOM configuration panel,
but we already have to trust them anyway on all but the bootload
IOM. Since the consequences of adding an IOM to the system with
incorrect switch settings can be catastrophic (the integrity of
the storage system could be compromised), we must make every
effort to verify as much of these switch settings as possible. A
clever use of the wrap-around channel of the IOM will be employed
here.
Just as it is possible for a CPU to appear in the config deck as
off when the system is booted, so will the IOM be able to be
marked as off at bootload time. This denotes an IOM which can
later be dynamically added. When adding an IOM, it will be
possible to specify whether to add only the IOM, or whether to
add everything which, according to the config deck, is connected
MTB-640 Page 9
8 SUBROUTINE DESCRIPTIONS
This section gives the declarations of the new subroutines which
will be added to Multics. These entries will be added to hphcs_
for the obvious reason.
______ ______
hphcs_ hphcs_
______ ______
Name: hphcs_
Entry: hphcs_$add_channel
The hphcs_$add_channel entry is used to add a logical
channel which is currently deleted to the pool of available
channels. An error will be returned if the channel to be added
is not the base logical channel of its physical channel and the
base logical channel is currently deleted. An error will also be
returned if the logical channel is connected to an I/O
multiplexer which is currently deleted.
Usage
dcl hphcs_$add_channel entry (char (8) aligned,
fixed bin (35));
call hphcs_$add_channel (chanid, code);
where:
chanid (Input)
is the identifier of the channel (e.g. "a19",
"b23").
code (Output)
is a standard system status code.
______ ______
hphcs_ hphcs_
______ ______
Entry: hphcs_$add_io_multiplexer
The hphcs_$add_io_multiplexer entry adds a currently deleted
I/O multiplexer to the pool of available multiplexers. The
multiplexer must appear in the config deck and be in the off
state. No logical channels connected to the multiplexer are
added by this call; they must be added by explicit calls to
hphcs_$add_channel.
Usage
dcl hphcs_$add_io_multiplexer entry (char (1),
fixed bin (35));
call hphcs_$add_io_multiplexer (tag, code);
where:
tag (Input)
is the tag which identifies the multiplexer in the
config deck. Currently acceptable tags are the
letters a through d.
code (Output)
is a standard system status code.
______ ______
hphcs_ hphcs_
______ ______
Entry: hphcs_$delete_channel
The hphcs_$delete_channel entry removes a currently
available logical channel from the pool of logical channels
available for I/O. A lgical channel cannot be deleted if it is
part of the only currently available path to an undeleted device.
A logical channel cannot be deleted if it is the base logical
channel of its physical channel and there are currently undeleted
logical channels of the same physical channel.
Usage
dcl hphcs_$delete_channel entry (char (8) aligned,
fixed bin (35));
call hphcs_$delete_channel (chanid, code);
where:
chanid (Input)
is the channel identifier.
code (Output)
is a standard system status code.
______ ______
hphcs_ hphcs_
______ ______
Entry: hphcs_$delete_io_multiplexer
The hphcs_$delete_io_multiplexer entry deletes an I/O
multiplexer from the current configuration. The specified
multiplexer must appear in the config deck and be in the on
state. All logical channels connected to the multiplexer must
have previously been deleted.
Usage
dcl hphcs_$delete_io_multiplexer entry (char (1),
fixed bin (35));
call hphcs_$delete_io_multiplexer (tag, code);
where:
tag (Input)
is the multiplexer tag as it appears in the config
deck. Acceptable values are the letters a through d.
code (Output)
is a standard system status code.
Page 14 MTB-640
9 COMMAND DESCRIPTIONS
This section gives the documentation of the new commands which
will be added to Multics.
______________ ______________
addchan (addc) addchan (addc)
______________ ______________
Name: addchan (addc)
SYNTAX AS A COMMAND:
addchan chanid {-control_args}
FUNCTION: adds the specified logical channel.
ARGUMENTS:
chanid
is the logical channel's chanid (e.g. a23, c53).
CONTROL ARGUMENTS:
-all, -a
adds any deleted devices which now have an I/O path available
to them. If any such devices are unable to be added, this
command will still succeed. Any devices so added will be
announced (unless -brief is used).
-brief, -bf
Causes any devices added by this command not to be announced.
NOTES:
When adding an IOM to a running system, it is imperative that its
switch settings be as described in Appendix A of The Operator's
Guide to Multics (Order No. GB61). While every effort is made
by software to verify these switch settings, the design of the
IOM prevents all relevant switch settings from being verified.
FAILURE TO ENSURE THAT THE IOM SWITCHES ARE SET CORRECTLY COULD
RESULT IN A DISASTEROUS CRASH.
EXAMPLES:
addchan b19 -bf -a
_____________ _____________
addiom (addi) addiom (addi)
_____________ _____________
Name: addiom (addi)
SYNTAX AS A COMMAND:
addiom tag {-control_args}
FUNCTION: adds the specified IOM.
ARGUMENTS:
tag
is the IOM's tag as specified in the config deck.
CONTROL ARGUMENTS:
-all, -a
adds all of this IOM's configured logical channels and any
deleted devices which now have an I/O path available to them.
If any such devices are unable to be added, this command will
still succeed. Any devices so added will be announced (unless
-brief is used).
-brief, -bf
Causes any devices added by this command not to be announced.
EXAMPLES:
addiom b -bf -a
______ ______
addmpc addmpc
______ ______
Name: addmpc
SYNTAX AS A COMMAND:
addmpc mpc_name {-control_args}
FUNCTION: adds the specified MPC, including its associated
physical and logical channels.
ARGUMENTS:
mpc_name
is the name of the MPC to be added (e.g. dskg, mtpc).
CONTROL ARGUMENTS:
-all, -a
adds any deleted devices which now have an I/O path available
to them. If any such devices are unable to be added, this
command will still succeed. Any devices so added will be
announced (unless -brief is used).
-brief, -bf
Causes any devices added by this command not to be announced.
EXAMPLES:
addmpc mtpa -a
addmpc: Also added devices tapa_01, tapa_02, tapa_03, and
tapa_04.
________ ________
addpchan addpchan
________ ________
Name: addpchan
SYNTAX AS A COMMAND:
addpchan chanid {-control_args}
FUNCTION: adds the specified physical channel as well as its
associated logical channels.
ARGUMENTS:
chanid
is the name of the physical channel to be added (e.g. a24,
b30). A physical channel is identified by the lowest numbered
logical channel which is part of the physical channel. For
example, if a physical channel is shared by logical channels
a24, a25, a26, and a27, it is identified as a24.
CONTROL ARGUMENTS:
-all, -a
adds any deleted devices which now have an I/O path available
to them. If any such devices are unable to be added, this
command will still succeed. Any devices so added will be
announced (unless -brief is used).
-brief, -bf
Causes any devices added by this command not to be announced.
EXAMPLES:
addpchan a18 -a
addpchan: Also added device tapa_03.
______________ ______________
delchan (delc) delchan (delc)
______________ ______________
Name: delchan (delc)
SYNTAX AS A COMMAND:
delc chanid {-control_args}
FUNCTION: deletes the specified logical channel.
ARGUMENTS:
chanid
is the name of the channel to be deleted (e.g. a32, b09).
CONTROL ARGUMENTS:
-force, -fc
deletes the channel even if it must delete unattached devices
to do so. No attached devices will be deleted, however, and
this command will fail if there are such attached devices. If
any unattached devices are deleted, they will be announced by
this command (unless -brief is used).
-brief, -bf
Causes any devices deleted by this command not to be
announced.
EXAMPLES:
delc a34
delc b27 -fc
delchan: Also deleted device prtc.
_____________ _____________
deliom (deli) deliom (deli)
_____________ _____________
Name: deliom (deli)
SYNTAX AS A COMMAND:
deld tag {-control_arg}
FUNCTION: deletes the specified I/O multiplexer.
ARGUMENTS:
tag
is the tag of the IOM to be deleted (i.e. a, b, c, or d)
CONTROL ARGUMENTS:
-force, -fc
deletes the channel even if it must delete unattached devices
and channels to do so. No attached devices will be deleted,
however, and this command will fail if there are such attached
devices. If any unattached devices are deleted, they will be
announced by this command.
EXAMPLES:
deli a
deli b
______ ______
delmpc delmpc
______ ______
Name: delmpc
SYNTAX AS A COMMAND:
delmpc mpc_name {-control_args}
FUNCTION: deletes the specified MPC including its associated
physical and logical channels.
ARGUMENTS:
mpc_name
is the name of the MPC to be deleted (e.g. mtpa, urpb).
CONTROL ARGUMENTS:
-force, -fc
deletes the MPC even if it must delete unattached devices to
do so. No attached devices will be deleted, however, and this
command will fail if there are such attached devices. If any
unattached devices are deleted, they will be announced by this
command (unless -brief is used).
-brief, -bf
Causes any devices deleted by this command not to be
announced.
EXAMPLES:
delmpc urpa
delmpc mtpa -fc
delmpc: Also deleted device tapa_03.
________ ________
delpchan delpchan
________ ________
Name: delpchan
SYNTAX AS A COMMAND:
delpchan chanid {-control_args}
FUNCTION: deletes the specified physical channel and its
associated logical channels.
ARGUMENTS:
chanid
is the name of the physical channel to be deleted (e.g. a24,
b30). A physical channel is identified by the lowest numbered
logical channel which is part of the physical channel. For
example, if a physical channel is shared by logical channels
a24, a25, a26, and a27, it is identified as a24.
CONTROL ARGUMENTS:
-force, -fc
deletes the physical channel even if it must delete unattached
devices to do so. No attached devices will be deleted,
however, and this command will fail if there are such attached
devices. If any unattached devices are deleted, they will be
announced by this command (unless -brief is used).
-brief, -bf
Causes any devices deleted by this command not to be
announced.
EXAMPLES:
delpchan a18 -fc
delpchan: Also deleted device tapa_03.
________________________ ________________________
vacate_pdir_volume (vpv) vacate_pdir_volume (vpv)
________________________ ________________________
Name: vacate_pdir_volume (vpv)
SYNTAX AS A COMMAND:
vacate_pdir_volume lvname
FUNCTION: moves all process directories on the specified logical
volume to other logical volumes. The process directories so
moved will be distributed among the other logical volumes which
are eligible to receive process directories. This command must
be given to move any process directories off a logical volume
which is about to be deleted.
ARGUMENTS:
lvname
is the name of the logical volume to be vacated.
EXAMPLES: vpv Temp;dlv Temp