MULTICS TECHNICAL BULLETIN MTB-737
To: MTB Distribution
From: Rich Fawcett
Date: 02/03/86
Subject: Dipper Documentation
The purpose of this MTB is to indicate the documentation changes
needed for "Dipper Support". This MTB is intended mainly for the
use of the documentation unit, but will give other readers an
idea of what is changing. The information in this MTB will be
referenced by some MCRs.
Comments on this MTB should be directed by Multics mail to:
System M: Fawcett.Multics
_________________________________________________________________
Multics Project internal working documentation. Not to be
reproduced or distributed outside the Multics Project.
MTB-737 Dipper Documentation
CONTENTS
Page
1 Introduction . . . . . . . . . . . . . . . . . . 1-1
What is DIPPER? . . . . . . . . . . . . . . . . 1-1
The Multidrop Interface (MDI) . . . . . . . . . 1-2
Operator Interface with the MCA . . . . . . . . 1-3
What are Subvolumes? . . . . . . . . . . . . . 1-4
New Devices . . . . . . . . . . . . . . . . . . 1-5
No More BOS . . . . . . . . . . . . . . . . . . 1-6
2 Multics System Maintenance Procedures (AM81-03) 2-1
System Description . . . . . . . . . . . . . . 2-1
Configuration . . . . . . . . . . . . . . . . . 2-1
Communicating With The System . . . . . . . . . 2-3
The Multidrop Interface (MDI) for IMUs . . . . 2-3
Bootload Operating System . . . . . . . . . . . 2-5
Bootload Command Environment . . . . . . . . . 2-5
Multics Configuration Deck . . . . . . . . . . 2-6
Responding to System Problems . . . . . . . . . 2-11
Dynamic Reconfiguration Procedures . . . . . . 2-11
Summary of Configuration Cards (apx A) . . . . 2-12
Startup Checklist of Switch Settings (apx C) . 2-12
Multics Disk Management (apx J) . . . . . . . . 2-12
3 Multics Subroutines And I/O Modules (AG93-05) . 3-1
System Input/Output Modules . . . . . . . . . . 3-1
4 Admin Maint Opr Commands (GB64-00) . . . . . . . 4-1
Privileged Multics Commands . . . . . . . . . . 4-1
Initializer Commands . . . . . . . . . . . . . 4-2
Initializer Exec Commands . . . . . . . . . . . 4-3
Volume Backup Daemon Limited Service . . . . . 4-3
BCE Commands . . . . . . . . . . . . . . . . . 4-3
Configuration Deck Description (A) . . . . . . 4-5
5 Multics Operators GUIDE To Multics (GB61-01) . . 5-1
Hardware Overview . . . . . . . . . . . . . . . 5-1
Software Overview . . . . . . . . . . . . . . . 5-2
Bootloading BCE . . . . . . . . . . . . . . . . 5-3
Editing The Config Deck to Change Hardware
states . . . . . . . . . . . . . . . . . . . . 5-9
Bringing the System Up . . . . . . . . . . . . 5-9
Managing User I/O Disk . . . . . . . . . . . . 5-9
Managing Storage System Disks . . . . . . . . . 5-10
Doing Dynamic Reconfiguration . . . . . . . . . 5-10
Dipper Documentation MTB-737
CONTENTS (cont)
Page
6 Multics System Administration Procedures
(AK50-03) . . . . . . . . . . . . . . . . . . . . 6-1
Hardware Overview . . . . . . . . . . . . . . . 6-1
Glossary of System Terms . . . . . . . . . . . 6-2
Disk Volume Registration . . . . . . . . . . . 6-2
Dipper Documentation MTB-737
1 INTRODUCTION
This MTB indicates the areas of the documentation that need to be
changed to support DIPPER. Most of the changes are not included
in any MCR due to the size of the changes. The wording and
format of the changes are left to the documentation group.
The format of this MTB is for each manual affected to be in a
separate section. Indications of what needs modified or added is
shown by paragraphs starting with "**", and the data to be used
follows that paragraph. Page numbers appear in the special
paragraphs for the reader's reference. Some of the documentation
examples are not available at this time and will be supplied in
the next rev to this MTB. These areas are indicated by "SUPPLIED
IN NEXT MTB REV".
The remainder of this section explains what needs to be
documented, and is intended to give the reader a better view of
the changes in later sections.
This MTB references a manual, "Information Multiplexer Unit
Hardware Operations Manual", at this time only the drawing number
is known (58010010). When the order number is known it will be
supplied in the next revision of this MTB.
What is DIPPER?
DIPPER is the code name given to the new hardware I/O system. In
the past this was also known by the name New I/O (NIO). The
mainframe is the Information Multiplexer Unit (IMU) which
replaces the IOM. The IMU differs from the IOM in many ways; the
main difference is the IMU is micro-processor controlled, while
the IOM is of older technology and its control is hard wired.
The channels in the IMU are called Integrated Peripheral
Controllers (IPC). The IPCs are numbered by physical location.
This number is used for internal configuration of the IMU and is
not the channel number (see "Operator Interface with the MCA"
page 1-3 ). There are several types of IPCs, some are
micro-processor controlled. The IMU supports up to 16 IPC.
The IPC-FIPS has the largest impact on Multics. This IPC allows
compliance to Federal Information Peripheral Standards and is
micro-processor controlled. It allows use of devices such as the
MSU3380 disks and the MTU8200 tapes, which are IBM compatible
devices. A significant difference from Honeywell peripherals is
that device numbers begin with 0 rather than 1. Honeywell
peripherals reserve device 0 for the MPC. Addressing the
controller is unnecessary for FIPS devices, since the firmware is
not loaded directly by the system. The interface is similar to
the IOM PSIA channel interface. The device controllers that
connect to this IPC are not like MPCs. The interaction between
MTB-737 Dipper Documentation
the IPC-FIPS and the externally connected controllers replace the
functions of the MPC. Unlike the MPC, there is no firmware to be
loaded by the host system, and the only software view of the
IPC-FIPS is that of a channel.
The IMU has a Maintenance Channel Adapter (MCA), another
micro-processor, that controls all initialization and maintenance
functions. These include loading the firmware for all
micro-processors, diagnostic test of all IPCs, IMU central,
memory interface logic, and self test of the MCA. The MCA plays
a major role in the fault processing for IMU hardware faults.
The MCA also controls the hardware function of booting the
system.
There are three communication paths for the MCAs. The system can
communicate with the MCA via the overhead channel number three
(3), this interface is defined in MTB663. The MCA can be
connected to the Remote Maintenance Interface (RMI), this
interface is not used on Multics systems. The remaining
interface uses the console IPC (IPC-CONS) in the IMU, via the
Multidrop Interface (MDI).
The Multidrop Interface (MDI)
The Multidrop Interface (MDI) connects MCAs and IPC-CONS in a
daisy-chain configuration. The MDI requires at least one
IPC-CONS connected to a console and one MCA. Multiple IPC-CONS
and MCAs may be connected, however only one console may be
enabled on the MDI, and identified as the master console; all
other consoles are slaves. The master console is the one to
which all operator communications with other connected MCAs is
routed. There are commands that allow the master console
designation to be moved from the current master to a slave;
however that slave IPC-CONS must have a console or terminal
connected.
It is required that each MCA be able to reach a master console.
If multiple IMUs are configured, then only one is required to
have an IPC-CONS, which in turn must be connected to a console or
terminal and be the master console on the MDI. If the operators
console, BCE console, is on the IMU, then it may be used as the
master. If not, then a separate console is required for the MDI,
and Multics requires that this console be in the configuration
deck as "alt". The hardware permits up to 16 MCAs on one MDI,
this means that the MCAs in IMUs of multiple systems can be on
one MDI. This type of configuration of one MDI for multiple
systems should be vigorously discouraged. Also each MCA and
IPC-CONS in an IMU can be a separate MDI, but must meet all the
hardware and software requirements for an MDI.
Dipper Documentation MTB-737
Because the master console may be the BCE console, the IPC-CONS
in the IMU uses an escape sequence to communicate with an MCA.
This convention uses an escape character of "#" to determine if
the input is for the MDI. There can be more that one MCA
connected to the MDI, therefore the MCA number must follow the
"#" character. To show that the MDI is active a ">" character is
printed by the console indicating the message is for an MCA. All
commands to the MCA are prefixed this way. All output messages
are prefixed similarly with #nn<. Where "#" is an indication
that this is from an MCA, "nn" is the MCA number, and "<"
indicates that this is an output message. For example, to set
the date and time in the MCA enter:
#01>time 111485,120000
The MCA responds with:
#01<Monday November 14, 1985. 11/14/85 (12:00:00)
The MCA number is determined by rocker switches on the MCA board
in the IMU. These switches must be set the to number
corresponding to the IMU's letter on the IOM card (e.g., 00 = A,
01 = B, etc). This is a Multics requirement for the MDI, but can
not be enforced by the software.
This convention of prefixing the input messages with the "#"
character only applies when the system does not have the console
open for read. If the console is open for read (normal operator
input) the "#" may still be used to delete a character. If it is
necessary to input to the MCA when the console is open for read,
an "ESC#nn" prefixes the message.
Operator Interface with the MCA
The operator interface to the MCA does not conform to accepted
Multics standards. The interface was not designed with any host
operating system in mind. It is a means by which the operator or
CSD personal can communicate with the hardware. In the age prior
to the micro-processor, information was passed between machine
and human by such devices as switches and lights. Very few of
these old devices exist on the IMU. The IMU must be told
everything, it assumes very little. The media by which the IMU
is informed are files on diskettes (the IMU has two 5 1/4 inch
drives) and the MDI master console.
The IMU needs to know the internal configuration to be used
within the IMU. This configuration is not the same as the
Multics software configuration deck. The IMU hardware
configuration files are stored on diskettes with filenames
prefixed with ".C". The contents of these files tell the IMU
such things as:
MTB-737 Dipper Documentation
o Each configured IPC must have a channel number and the
number of logical channels.
o Type of IPC and if firmware is required the firmware
revision.
o The tape drive from which the system will be booted.
o How many SCUs are connected.
o The size and order of the memories.
o Initialize from the SCU is enable.
o That the IMU will be on a Multics system.
There can be up to 4 configuration files. The method of
inputting all this information is defined in the hardware manual
"Information Multiplexer Unit Hardware Operations Manual"
58010010. This manual explains how to power up and down the IMU,
how to build a configuration file, and many other interesting
things on the MDI and MCA. There are also some very
uninteresting things. These are how the GCOS consoles fit into
the MDI world, and how the MDI relates to the Remote Maintenance
Interface (RMI); neither are used on a Multics system. The
Multics Documentation Unit should not try to rewrite this manual,
but rather supplement this manual with the following type of
information.
The Remote Maintenance Interface (RMI) is never used on a Multics
system.
The master console for the MDI must be configured in the Multics
configuration deck. It is the site's option to have the MDI
communications on the same console as the operator console (BCE
console), or to have a dedicated console for MDI information. If
the second option is chosen then this console must be configured
as "alt" in the Multics configuration deck.
The reason for having the MDI master configured on the system is
so that Multics can disable the MDI input to the MCA. There are
some maintenance functions that could have an adverse effect on
the operating system. Also there is the potential of data
compromise from improper or malicious use of the MCA. If the
operating system controls the disabling (locking) and enabling
(unlocking) of MCA input requests, valid maintenance functions
can still be performed while security audit trails of the lock
and unlock are placed in the syserr_log.
What are Subvolumes?
Subvolume implementation has been the method chosen to support
the MSU3380 and MSU3390 disk devices. A subvolume is defined as
a portion of a "physical device" that contains one complete
Multics file system "physical volume". This division is done by
the software, and not by the hardware. The MSU3380 and MSU3390
are the only devices divided into subvolumes. In this
Dipper Documentation MTB-737
implementation the devices are divided into equal size parts.
MSU3380 is divided in half, two subvolumes, while the MSU3390
contains three subvolumes. Each subvolume of a device is named
by a single character. MSU3390 subvolume names are a, b, and c,
the names for MSU3380 are a, and b. When there is a need to
relate the physical volume to the physical device that contains
it, the subvolume name is appended to the device name (example
dska_01b). MTB731 defines this implementation.
User IO for the MSU3380 and MSU3390 still requires that RCP
attach the entire device to the user. However the user may do IO
to more than one subvolume via rdisk_ or the entire device (see
page 3-1). The user IO to these drives requires changes to disk
authentication messages (see page 5-10).
New Devices
The new tape subsystem that is supported may have MTU8205,
MTU8206 and MTU8208 tape drives. The specifications for these
drives are:
MTU8205 125 ips, 800/1600 bpi
MTU8206 125 ips, 1600/6250 bpi
MTU8208 200 ips, 1600/6250 bpi
This tape subsystem does not have an MPC as the tape controller.
The controller is contained in the first tape drive in the string
(the head of string device). This connects to the IPC-FIPS in
the IMU and is not supported on the IOM. The real model numbers
for these device that contain the controller and a tape handler
are MTS8205, MTS8206 and MTS8208, the difference being the tape
handler device. The system will reference only the tape drive
because the firmware for this controller is not loadable by the
system.
The new disk devices that are supported are the MSU3380 and
MSU3390. These devices may be connected on the same subsystem.
This type of subsystem is only supported on the IMU. The disk
subsystem contains a storage director, disk devices that are
string controllers and devices that are just disk devices. The
IPC-FIPS in the IMU connects to storage director, has two halves
and can be "cross-barred" to two IPC-FIPS. The firmware for the
storage director, and the head of string controller cannot be
loaded by the system. The system configuration will only define
the devices. Each device cabinet contains two spindles, each
spindle has two actuator arms. Each arm defines a portion of the
spindle and is referenced as a separate device, data under one
arm cannot be accessed by the other.
Multics only supports these devices formatted at 512 words per
sector. Each cylinder of the MSU3380 and MSU3390 has 255
MTB-737 Dipper Documentation
sectors, or 127 pages with one sector unusable. The MSU3380 has
885 cylinders, the MSU3390 has 1770 cylinders. These devices are
divided into subvolumes. The MSU3380 is divided into two
subvolumes, 442 cylinders each with one cylinder unused, or 56134
records per subvolume. Each MSU3380 cabinet contains 449072
records (a cabinet contains 4 arms two subvolumes each). The
MSU3390 is divided into three subvolumes, 590 cylinders each with
none unused, or 74930 records per subvolume. Each MSU3390
cabinet contains 899160 records (a cabinet contains 4 arms three
subvolumes each). For comparison a 501 drive cabinet (2
spindles, 1 arm per spindle, 4 physical volumes total) has 268800
records, a 16 drive 451 subsystem has 612128 records. A disk
subsystem of 4 MSU3390 cabinets would contain 16 actuator arms
and hold 3,596,640 records (equal to 94 MSU451s).
No More BOS
There will be no support for DIPPER in BOS. In MR12, all the
useful functions of BOS will be replaced by similar functions in
BCE. Therefore, all references to BOS in Multics documentation
should be deleted. If resources are available a section in some
manual should relate the old BOS functions to the BCE functions.
Dipper Documentation MTB-737
2 MULTICS SYSTEM MAINTENANCE PROCEDURES (AM81-03)
System Description
** Change the first sentence in the paragraph under HARDWARE to
include the IMU (page 2-1).
HARDWARE
A Multics configuration consists of one or more central
processor units (CPUs), one or more IO mainframe units (IOMs or
IMUs) for peripheral interfacing, and one or more Front-End
Network Processors (FNPs) for data communication interfacing.
** Change the first sentence under MEMORY to include the IMU
(page 2-1).
The memory system is composed of one or more SCUs that
interface directly with CPUs, IOMs, IMUs, and the memory store
units that contain the manipulated data.
** Change the block diagram Figure 2-1 (page 2-2), to show that
the block labeled INPUT/OUTPUT MULTIPLEXER could also be an
IMU.
** Add a paragraph for the IMU (page 2-3).
INFORMATION MULTIPLEXER UNIT
The IMU functions much like the IOM for the Multics
configuration (as an I/O Processor).
Configuration
** Add some information for configuring the IMU via the MCA.
(page 3-28).
INFORMATION MULTIPLEXER UNIT
Unlike other mainframes in the system configuration, the IMU
has no configuration panel with switches. All the functions of
configuration are done by the MCA. The MCA uses the
configuration files stored on diskettes. The configurator MCA
command is CONFIG. The command is a menu driven command. The
command and menus are explain in the "Information Multiplexer
Unit Hardware Operations Manual" 58010010. A few of the menu
functions are explain below.
MTB-737 Dipper Documentation
The IMU and BOOTSTRAP information is entered with item 4 of the
config menu. When this item is selected, the MCA prompts with
a configuration topic and shows the current value and the
acceptable input values. A response of CR keeps the current
value.
o "IMU number" is the corresponding number to the name of
the IMU being configured (e.g., A = 0, B = 1, etc).
o "host oper system" is the type of operating system the IMU
is to run with. (e.g., 2 = Multics)
o "Level1-remote maintenance allowed" enables the RMI and
should always be answered by typing "N".
o "The lowest MCA number" is the lowest MCA number to be
connected to the MDI.
o "Total number of MCA" is the total number of MCAs to be on
the MDI.
o "bootstrap enable" indicates if this IMU can boot the
system.
o "bootstrap automatic" this should be answered by typing
"N".
o "bootstrap scu port number" is the port number of the SCU
through which connects are sent to the IMU (the port on
the SCU this IMU is connected to).
o "bootstrap source" is the device type to boot from. The
response of 2 for tape should be entered. At present
Multics can only boot from tape.
o "bootstrap primary channel number" this is the channel
number of the bootload tape subsystem.
o "interrupt base address" is the address for the Interrupt
Multiplexer Words, and is calculated by the MCA using the
"oper system" and the "IMU number". A response of CR
should be given.
o "mailbox base address" is the address where the software
places the control words in memory, and is calculated by
the MCA using the "oper system" and the "IMU number". A
response of CR should be given.
Dipper Documentation MTB-737
The memory port configuration is entered with item 5 of the
config menu.
o "enter memory port number A-D" this is requesting the
memory port.
o "memory port enable" is means will the IMU uses this port.
o "memory port initialize" this will enable (Y) or disable
(N) the acceptance of the the system initialize signal
from this port.
o "memory port starting address" this sets the starting
address for this memory. The responses may be selected
from the following table.
MEM SIZE 256K 512K 1M 2M 4M
P S A 0 0 0 0 0
O T D 256K 512K 1M 2M 4M
S A D 512K 1M 2M 4M 8M
S R R 768K 1536K 3M 6M 12M
I T E 1M 2M 4M 8M
B I S 1280K 2560K 5M 10M
L N S 1536K 3M 6M 12M
E G 1792K 3584K 7M 14M
o "memory port size" this is the size of the memory on this
port. The valid responses are: 256K, 512K, 1M, 2M, 4M.
o "memory port interlace" this enables (Y) disables (N) the
interlacing of two memory ports. It is recommended that
SCU port not be interlaced on a Multics system, response
(N).
Communicating With The System
** Remove all references to BOS
** Add before the topic heading "The Initializer Terminal" (page
4-3).
The Multidrop Interface (MDI) for IMUs
On systems that have IMUs as an IO Mainframe there is a need to
communicate with the IMUs Maintenance Channel Adapter (MCA).
The MCA controls the hardware function of system booting, IMU
maintenance (e.g. IPC firmware loading, etc), and some
MTB-737 Dipper Documentation
hardware control functions for the IMU. There are three
hardware components involved to communicate with the MCA.
These are: the MCA, the console channel in the IMU (IPC-CONS),
and a console or terminal. These are connected together to
form the Multidrop Interface.
The Multidrop Interface (MDI) connects MCAs and IPC-CONS in a
daisy-chain configuration. The MDI requires at least one
IPC-CONS connected to a console and one MCA. Multiple IPC-CONS
and MCAs may be connected, however only one console may be
enabled on the MDI, called the master console; all other
consoles are slaves. The master console is the one to which
all operator communications to all connected MCAs is routed.
There are commands that will allow the master console
designation to be moved from the current master to a slave;
however that slave IPC-CONS must have a console or terminal
connected.
It is required that each MCA must be able to reach a master
console. If multiple IMU's are configured then only one is
required to have a IPC-CONS, it must be connected to a console
or terminal and be the master console on the MDI. If the
operators console, BCE console, is on the IMU then it may be
used as the master. If not then a separate console is required
for the MDI, and Multics requires that this console be in the
Multics configuration deck as "alt". All the MCAs and IPC-CONS
on the system may be connected together on one MDI, or each MCA
and IPC-CONS in an IMU can be a separate MDI, or other
combinations, but must meet all the hardware and software
requirements for an MDI.
Because the master console may be the BCE console, the IPC-CONS
in the IMU uses an escape sequence to communicate with an MCA.
This convention uses an escape character of "#" to determine if
the input is for the MDI. There can be more that one MCA
connected to the MDI therefore the MCA number must follow the
"#" character. To show that the MDI is active a ">" is printed
by the console indicating the message will be for an MCA. All
commands to the MCA are prefixed this way. All output messages
are prefixed similarly with #nn<. Where "#" is an indication
that this is from an MCA, "nn" is the MCA number, and "<"
indicates that this is an output message. For example to set
the date and time in the MCA:
#01>time 111485,120000
The MCA will respond with:
#01<Monday November 14, 1985. 11/14/85 (12:00:00)
The MCA number is determined by rocker switches on the MCA
board in the IMU. These must be set to number corresponding to
Dipper Documentation MTB-737
the IMU's letter on the IOM card (e.g., 00 = A, 01 = B, etc).
This is a Multics software requirement for the MDI.
This convention of prefixing the input messages with the "#"
character only applies when the system does not have the
console open for read. If the console is open for read, normal
operator input, the "#" may still be used to delete a
character. If it is necessary to input to the MCA when the
console is open for read, an "ESC#nn" prefixes the message.
Bootload Operating System
** Delete this section (pages 5-1 to 5-5)
Bootload Command Environment
** Change to the response of Enter rpv data: (page 6-2)
cold Tchan msp_model drive_model drive_number{sv}
** Change mpc_model to msp_model (page 6-2)
msp_model
is the model number (in decimal) of the bootload disk
controller. Valid model numbers are:
400 (MSP0400)
451 (MSP0451, DSC451)
601 (MSP0601)
603 (MSP0607)
609 (MSP0609)
611 (MSP0611)
612 (MSP0612)
800 (MSP8000)
ipc (IPC-FIPS)
drive_model
is the model number (in decimal) of the disk drive on which
the RPV is located. Valid model numbers are:
400 (MSU0400)
402 (MSU0402)
451 (MSU0451)
500 (MSU0500)
501 (MSU0501)
3380 (MSU3380)
3390 (MSU3390)
MTB-737 Dipper Documentation
drive_number{sv}
is the alphanumeric number, and if the drive_model is 3380
or 3390 the subvolume, of the disk drive on which the RPV is
mounted. The valid subvolume names for MSU3380s are a and
b, for MSU3390s a, b and c. This must be given for the 3380
and 3390 devices, and must be omitted for all other disk
drive types. (e.g. 1 for 451, or 1b for 3380).
Multics Configuration Deck
** Change the list of Config card categories (bottom of page 7-1)
Config cards can be divided into five categories:
1. configuration of major hardware mainframe modules: cpu,
iom, mem
2. configuration of peripheral controllers and devices: chnl,
mpc, ipc, prph, udsk
3. descriptions of software parameters: clock, schd, sst, tcd
4. parameters of the storage system: part, root, salv
5. specialized: dbmj, intk, parm, tbls.
** Change General Description of Config Cards (page 7-2)
All cards in the config deck contain free-formatted individual
fields separated by one or more blank characters. Numbers on
config cards are usually octal (part and root cards are
exceptions). Decimal numbers are represented by placing a
decimal point immediately after the number (e.g., 10.
indicates decimal ten). In some card fields, numbers 1 through
8 may be represented by the letters a through h, respectively.
See examples listed under individual cards.
** The part card definition change for the MTB is on page 2-9,
and the root card is on page 2-10.
** Add to the sample config (page 7-3)
iom c 2 imu on
prph opcc c 14. 6601. 80. alt
prph dskg c 16. 4 3380. 16.
chnl dskg c 20. 4
ipc fips c 16. 4
ipc fips c 20. 4
Dipper Documentation MTB-737
** Remove the "." from the root and part cards (page 7-3) The
part card definition change for the MTB is on page 2-9, and the
root card is on page 2-10.
** Add to the sample config (page 7-4)
iom -tag c -port 2 -model imu -state on
prph -device opcc -iom c -chn 14. -model 6601. -ll 80.
-state alt
prph -subsys dskg -iom c -chn 16. -nchan 4 -model 3380.
-number 16.
chnl -subsys dskg -iom c -chn 20. -nchan 4
ipc -type fips -iom c -chn 16. -nchan 4
ipc -type fips -iom c -chn 20. -nchan 4
** Remove the "." from the root and part cards (page 7-4). The
part card definition change for the MTB is on page 2-9, and the
root card is on page 2-10.
** Change the iom card (page 7-13)
Name: iom
The iom card describes the IO mainframe (IOM or IMU) as part
of the system configuration.
Format
iom tag port model state
where:
1. tag
is a letter (a, b, c, or d) that identifies the IOM.
2. port
is the system controller port (0 through 7) to which the
IOM or IMU is connected. It is strongly recommended that
IO mainframes be configured on lower-numbered SC ports
than CPUs.
3. model
May be either iom indicating that this IO mainframe is an
IOM, or imu for IMU type IO mainframe.
4. state
is either on, indicating that the IO mainframe may be used
by the System, or off indicating that it may not be used
at this time. If off, it may be added to the
configuration at a later time.
MTB-737 Dipper Documentation
Labeled Format
iom -tag tag -port port -model model -state state
Examples
iom a 0 iom on
iom -tag a -port 0 -model iom -state on
iom c 3 imu on
iom -tag c -port 3 -model imu -state on
** Add definition of ipc card after the iom card (page 7-13)
Name: ipc
The ipc card is used in the configuration deck to associate
channel numbers with the IPC FIPS controllers. FIPS
controllers are only supported for the IMU type IO Mainframe.
The physical channels for this type of IO Mainframe are called
IPCs. There must be a separate ipc card for each IPC FIPS
controller configured on the system.
Format
ipc type iom chan nchan
where:
1. type
is the type of IPC. Only the "fips" type is required to be
in the config deck.
2. iom
is the IOM for the IPC connected.
3. chan
is the starting logical channel number for this IPC.
4. nchan
is the number of logical channels for this IPC.
Labeled Format
ipc -type fips -iom iom -chn chn -nchan nchan
Examples
ipc fips a 20. 2
Dipper Documentation MTB-737
ipc -type fips -iom a -chn 20. -nchn 2
Note:
** Change the part card format to be: (pages 7-19 7-20)
Name: part
Part cards inform BCE and Multics of the location of areas
of the disk used for various partitions.
Format
part partname subsystem drive{sv}
where:
1. partname
is the name of the partition residing on a particular volume
or subvolume. The system consults the label of that
physical volume to determine where the records of the given
partition reside. The one partition commonly used is:
dump
area of disk used to contain dump image.
2. subsystem
is the name of the peripheral subsystem.
3. drive{sv}
is the decimal number of the drive, and the subvolume name
{sv} if MSU3380 or MSU3390, on which the partition is
located. This is an alphanumeric field and does not accept
a period (.).
Labeled Format
part -part partname -subsys subsystem -drive drive{sv}
** Change to Examples (page 7-20)
Examples
part dump dskb 1
part -part dump -subsystem dskb -drive 1
MTB-737 Dipper Documentation
The above cards state that a DUMP partition resides on the
volume located on drive 1 of disk subsystem DSKB, and the drive
is not a MSU3380 nor a MSU3390.
part dump dske 3b
part -part dump -subsys dske -drive 3b
The above example states that a DUMP partition resides on
drive 3 subvolume B of disk subsystem DSKE.
** Add to the prph card list of valid model numbers for disk
drives (page 7-21)
3380. MSU3380
3390. MSU3390
** Add to the prph card list of valid model numbers for tape
drives (page 7-22)
8200. MTU8200
** Change the format of the root card (page 7-26)
Format
root subsystem1 drive1{sv} {...subsystemN driveN{sv}}
where:
1. subsystemi
is the name of the peripheral subsystem on which a physical
volume of RLV is located.
2. drivei{sv}
is the decimal number of the drive, and the subvolume name
{sv} if MSU3380 or MSU3390, on which the physical volume is
located. This is an alphanumeric field and does not accept
a period (.).
Labeled Format
root -subsys subsystem1 -drive drive1{sv} {... -subsystemN
-driveN{sv}}
Dipper Documentation MTB-737
** Change Examples of root card (page 7-27)
Examples
root dska 1 dska 2 dskc 0a dskc 1b
root -subsys dska -drive 1 -subsys dska -drive 2 -subsys
dskc -drive 0a -subsys dskc -drive 1b
** Change the first sentence under the example (page 7-27) to
read:
In these examples, assume that the RLV is located on 451
drives DSKA 1 and DSKA 2, also 3380 drives DSKC 0 subvolume
A and DSKC 1 subvolume B.
Responding to System Problems
** All references to BOS must be removed from this section when
the appropriate data is available for BCE.
Dynamic Reconfiguration Procedures
** Change the Notes about the IOMs to include the IMU (page
11-2). This should be changed to Notes on adding IO mainframes
Notes on Adding IO mainframes
There are two types of IO mainframes used on a Multics
system, IOMs and IMUs. They are both defined by an iom card in
the configuration deck, the model field is either iom or imu.
Therefore the device type to be used with the rcf command is
iom.
IO mainframe configuration settings are checked for
consistency before the IO mainframe is added to the system.
You can bypass this validity check by adding the dris parameter
to the parm card in the config deck. See Section 7 for
details.
Before you add an IO mainframe to the configuration, you
must initialize it. The procedure for doing this is included
in the procedure for adding an IO mainframe in the "Operator's
Guide to Multics", Order No. GB61.
MTB-737 Dipper Documentation
** Add ipc card (page A-2).
ipc
Format:
ipc fips iom chan nchan
Labeled Format
ipc fips -iom iom -chn chn -nchan nchan
defines the channels and the IMU for an IPC-FIPS channel.
Startup Checklist of Switch Settings (apx C)
** Add to Appendix C a note about the IMU.
IMU CONFIGURATION
The IMU MCA configuration files replace the function of switch
settings for the IOM. The values placed in the configuration
files of the MCA are similar to the values of the switches on
the IOM. These values are placed in the MCA configuration
files via the MCA command CONFIG. If the configuration file to
be used is other that the default assigned the name must be
given with the MCA commands IBOOT and INIT. The MCA commands
are defined in the "Information Multiplexer Unit Hardware
Operations Manual".
Multics Disk Management (apx J)
** Change the "Disk Management Mechanisms -- Hardware and
Software" to include the MSU3380 and MSU3390 devices. In most
cases the references to MPC will be changed to disk controller.
This will start on page J-5.
** Add after the first paragraph under the heading "Disk
Management Mechanisms -- Hardware and Software".
There are two basic classes of hardware disk subsystems. The
first is the Honeywell supplied that consist of device styles
400, 451, 500, and 501. This class of disks is supported on
both types of IO Mainframes, IOM and IMU. These style devices
have Micro-Programmed Controllers (MPCs) disk controllers which
interface with the system and disk drives. An MPC is a stored
program computer which can be loaded with firmware by the
system, and can execute various commands to control disk
operations. Each command is a program with the MPC memory
which ties up the MPC until command completion.
The other class are the device styles 3380 and 3390. This
class of disks are only supported with the IMU IO Mainframe,
and conform to the Federal Information Peripheral Standard
Dipper Documentation MTB-737
(FIPS). The disk controller functions for the FIPS style
devices are done by a combination of three hardware components;
the head-of-string device, the storage director, and the
IPC-FIPS IMU channel. This IPC-FIPS channel in the IMU allows
the system to interface to the FIPS style disk subsystem in the
same manner as the MPC style subsystem. For this explanation
it works similar to the MPC, and can be considered the disk
controller. However the firmware is not loadable via the
system.
** Delete the first paragraph under "Disk Controllers" (page
J-5). sp 1
** In the remaining two paragraphs on page J-5 replace
"MPC" with "disk controller".
** Change topic heading "Physical Channels" to "Physical Channels
for MPCs" (page J-6). In the paragraph under this heading
change IOM to IO Mainframe.
** Add before the topic heading "Logical Channels" (page J-6).
IPC-FIPS Physical Channel
This channel reacts similar to the physical channel for the
MPC. It connects to a port on the storage director. There are
two storage directors in a cabinet. Each storage director can
be connect to the same head-of-string device cabinets. This
allows dual porting to the FIPS devices. Each physical channel
can only perform a single I/O data transfer at a time.
** In the paragraphs under "Logical Channels" change "IOM" to "IO
Mainframes". Change "MPC" to "disk controller".
** Add a note about subvolumes in the "Drive Queues" topic (page
J-9).
Note: The FIPS style devices are divided into subvolumes.
When the disk DIM is called the subvolume record address is
converted to a device record address. This allows the disk DIM
to manage and meter the device as one entity and need not track
each subvolume.
Dipper Documentation MTB-737
3 MULTICS SUBROUTINES AND I/O MODULES (AG93-05)
System Input/Output Modules
** Changes to the attach description for rdisk_ (page 3-122)
** Add to the device_id list.
d338 for the MSU3380
d339 for the MSU3390
** Add the device control argument
-device, -dv DEVICE_NAME
indicates what disk drive DEVICE_NAME is to be attached.
This is useful when attaching to drives that do not have
removable media. DEVICE_NAME has the form of:
dskX_NN{S}
where:
X
is the subsystem name.
NN
is the device number.
S
is the subvolume name. Only valid for d338 and d339
device_ids. Valid subvolume names for d338 are a and
b, for the d339 a, b and c.
** Change the notes to read (page 3-122).
NOTES
The attachment causes the specified disk pack to be mounted on
a drive of the specified type.
When the -device option is given with a subvolume, rdisk_ will
perform the address conversions in the same manner as the file
system IO. More that one subvolume of a device may be attached
by a process. The device may only be attached to one process
at any one time. If the subvolume name is not given for a
device that supports subvolumes, then rdisk_ will not convert
the addresses and the entire device may be accessed.
Dipper Documentation MTB-737
4 ADMIN MAINT OPR COMMANDS (GB64-00)
Privileged Multics Commands
** Add to the add_volume_registration command model list of disk
devices (page 2-4). Also note that "-drive_midel" should be
-drive_model.
3380 (MSU3380)
3390 (MSU3390)
** Add to the change_volume_registration command model list of
disk devices (page 2-72)
3380 (MSU3380)
3390 (MSU3390)
** Add the following argument to documentation of
io_error_summary. This command is currently on page 2-283 but
appears to be out of alphabetical order.
-io_command, -ioc
display the I/O command that was being executed when the
abnormal status occurred. The command will be displayed
in octal, in parenthesis, prior to the interpreted status.
** Add to the example of the list_vols output devices that have
subvolume names appended. (page 2-302 & 303)
TO BE SUPPLIED IN NEXT MTB REV
** In the definition of the vtoc_buffer_meters add the definition
of the RAR. (page 2-553)
The last section of the output (labelled "Disk I/Os") list the
number of disk reads and writes for VTOCs. This section also
includes the RAR meter. This RAR meter is the number of
software read-alter-rewrites. This RAR function is only done
for the MSU3380 and MSU3390.
EXAMPLES
TO BE SUPPLIED IN NEXT MTB REV
MTB-737 Dipper Documentation
** Change the definition of the drive_name argument for the
add_vol command (page 4-13)
drive_name
has the form <subsys>_<nn>{sv}. e.g., dskb_00c for devices
that are divided into subvolumes, and dska_02 for devices
that are not divided into subvolumes. This argument may be
-all to cause the system to read and check the labels of all
assumed physical volumes.
** Change the definition of the drive_name argument for the
del_vol command (page 4-20)
drive_name
has the form <subsys>_<nn>{sv}. e.g., dskb_00c for devices
that are divided into subvolumes, and dska_02 for devices
that are not divided into subvolumes.
** Add the command lock_mca (page 4-35)
Name: lock_mca
Syntax as a command
lock_mca
Function
Locks (disables) input to all MCAs from the console.
** Add to the device model list for the reload_volume command
under the -disk_model control argument (page 4-62).
d338
d339
** Add the new control argument -pvname_device to the
reload_volume command (page 4-63). MTB731 contains information
on the reason for this change in the section titled "Volume
Reloader and Rdisk_".
-pvname_device, -pvdv STRP1 STRD1...STRPn STRDn
specifies the name(s) of the physical volume(s) to be
reloaded, and what device(s) the volume(s) will be on.
STRPi and STRDi make up an ordered pair list of pvname
(STRPi) followed by the device_name (STRDi) that will
contain the physical volume. This control argument is
useful when reloading devices that have fixed media and is
the only way to reload a physical volume to a subvolume of a
Dipper Documentation MTB-737
device. This may only be used with the default output
attach description. The device usage must be set for "io"
by the set_drive_usage command. If this control argument is
used there is not need to use the assign_resource command.
Example
-pvname_device pub01 dska_00a pub02 dska_00b
** Add the command unlock_mca (page 4-83)
Name: unlock_mca
Syntax as a command
unlock_mca mca_number
Function
Unlocks (enables) console input to the MCA specified by the
mca_number.
Argument
mca_number
is the decimal number of the MCA to be unlocked, and is
required.
Initializer Exec Commands
** Change the auth command related to disk (pages 5-3 and 4)
TO BE SUPPLIED IN NEXT MTB REV
Volume Backup Daemon Limited Service
** Add the -pvname_device control arguments to the reload_volume
(page 7-21).
See page 4-2 of this MTB.
BCE Commands
** Delete the BCE command bos command (page 9-5).
MTB-737 Dipper Documentation
** Change the example under config_edit command (page 9-6) from
nsa to imu.
** Change the display_disk_label command (page 9-8) to show
subvolumes.
ARGUMENTS
device
specifies the disk subsystem, drive and if the device is a
3380, or 3390 the subvolume on which the physical volume
is located (e.g. dska_07, or dskc_00b).
EXAMPLES
** NEW EXAMPLES WILL BE SUPPLIED IN THE NEXT REV OF MTB.
** Change the -drive control argument for the dump command (page
9-11).
-drive, -dv drive_name
places the dumps into the dump partition of the volume
specified instead of the drive listed on the PART DUMP
card. (e.g. dska_07 or dskc_01b for drives with
subvolumes).
** Add the BCE command lock_mca (page 9-17).
See page 4-2 of this MTB.
** Change the "disk" address form for the BCE probe command (page
9-20). disk(drive_name,record_num,offset)
refers to a specific page of a disk drive. The drive is
in the standard form of dsk<subsys>_<number>{subvol}. For
example dska_07, or dskc_00b for devices with subvolumes.
Both record_num and offset (within the page) are assumed
to be octal if a base designator is not specified.
** Change the disk argument for the BCE test_disk command (page
9-30).
device
is a disk known to the system (e.g., dska_03, or dskc_06c
for devices that have subvolumes).
** Add the BCE command unlock_mca (page 9-31).
See page 4-3 of this MTB.
Dipper Documentation MTB-737
Configuration Deck Description (A)
** Replace the configuration deck in appendix A.
TO BE SUPPLIED IN NEXT MTB REV
Dipper Documentation MTB-737
5 MULTICS OPERATORS GUIDE TO MULTICS (GB61-01)
Hardware Overview
** Add after Input/Output Multiplexer (IOM) and before Front-End
Network Processor (FNP) on page 2-2 the following:
Integrated Multiplexer Unit (IMU)
The IMU is a functional replacement for a DPS 8 IOM. It is
controlled by internal micro-processors. All switch functions
are done via a console to Maintenance Channel Adapter (MCA), a
micro-processor, in the IMU. The IMU channels are called
Integrated Peripheral Controllers (IPC). The IPCs connect the
IMU to peripherals or other controllers, such as consoles, FNPs
and MPCs. There can be up to 4 IMUs in a Multics configuration
and can be mixed on the system with IOMs, for a total number of
IOMs and IMUs not exceeding 4. The IMU is defined in the
system configuration deck using an iom card (see section 3).
** Change the wording of the first paragraph under DISKS
substituting controller for MPC (page 2-4). This change should
be made due to the addition of the IPC-FIPS that controls the
access to FIPS disk via the storage director.
Disks are principal means of storing information on Multics.
An individual disk unit is called a disk pack. The device
which houses packs is a disk drive. Access to the drives is
controlled by a disk controller. Some disk drives are cross
barred. This means that they are connected to more than one
disk controller. The advantage of this is that if one disk
controller fails, the disk drives connected to it can still run
because the other controller will pick up its load.
** Change the last paragraph on page 2-4 to read:
You will often hear the word "Volume" used in reference to
disks. A physical volume is a set of data accessed as a group.
Some disk packs contain one physical volume, while others
contain two or three. A logical volume is a set of physical
volumes which have some logical relationship to each other.
For a detailed discussion of disk volumes, see "Disk Volumes"
in section 3.
** Change the first paragraph on page 2-5 to read:
There are different models of disks. The first way they differ
is in whether they contain one or more physical volumes, and
how they are divided. The second way they differ is in whether
MTB-737 Dipper Documentation
or not the packs are demountable. The third way is in how much
information they can hold. Older disks, such as 451s, contain
one physical volume, have demountable packs and hold less
information. The 500s and 501s contain two physical volumes
divided by the MPC firmware, the packs are not demountable, and
hold more information. The MSU3380 and MSU3390 contain two and
three physical volumes respectively. The division of the
physical volumes on MSU3380s and MSU3390s is done by Multics
file system software and is referred to as a subvolume. These
devices hold more information that the 501, the MSU3390 being
the largest.
** Change the definition of MASS STORAGE PROCESSOR (page 2-5).
MSPs are devices which control disk drives. They are often
called disk controllers. There are two basic types used, the
MPC and the IPC-FIPS. These devices are defined in the
configuration deck by the mpc and ipc cards respectively.
The IPC-FIPS is a channel in the IMU and connects to the
disk drives via a disk storage director.
** Change the definition of MAGNETIC TAPE PROCESSOR (page 2-5).
MTPs are devices which control tape drives. They are often
called tape controllers. There are two basic types used, the
MPC and the IPC-FIPS. These devices are defined in the
configuration deck by the mpc and ipc cards respectively.
The IPC-FIPS is a channel in the IMU and connects to a tape
head of string controller in MTS8200 subsystem.
Software Overview
** Change the first paragraph in the definition of disk volumes
(page 3-1). The following three paragraphs should replace it.
DISK VOLUMES
The storage system is divided into logical volumes so it can
be managed one piece at a time. A logical volume is made up of
one or more physical volumes, which are sets of data accessed
as groups.
These physical volumes are contained on disk packs. The
number of physical volumes on a disk pack, and how they are
separated is dependent on disk model type. Model 451 disks
have only one physical volume per disk pack and therefore
Dipper Documentation MTB-737
requires no separation. The 500/501 disks have two physical
volumes per disk pack and are separated by device numbers
managed by the disk controller firmware. Models 3380/3390 are
divided into subvolumes controlled and managed by the Multics
system software. Each subvolume contains one physical volume.
There are two subvolumes on the 3380s and three on the 3390s.
The relationship between the logical volume "Public" and its
constituent physical volume "pub1" is like the relationship
between an encyclopedia and its Volume A. You should note that
there is no fixed correspondence between the name of a logical
volume and the names of the physical volumes which constitute
it. However most sites do adopt some kind of correspondence by
convention. Your system administrator can tell you if there is
a convention in use at your site.
Bootloading BCE
** Add this NOTE to page 11-1
TO BOOT BCE FROM SCRATCH
NOTE:
The Honeywell hardware manual "Information Multiplexer Unit
Hardware Operations Manual" (58010010) defines the MCA commands
and how to communicate with the MCA. If the system has
multiple IMUs configured the messages from the MCAs in step 15
may be intermixed. Each message will be prefixed by "#nn<".
Where, "#" indicates this is a message from an MCA, "nn" is the
MCA number, and "<" indicates this message is an output
message.
** Add at the correct places the differences for IMU/MCA booting.
(pages 11-1 to 11-5) starting with step 2.
2. If the tape is mounted on a 500 tape drive, ready it by
pressing the LOAD button, waiting for the BOT light to go
on, then pressing the READY button. If the tape is
mounted on a 600, 610 or 630 tape drive, ready it by
pressing the START button. If the tape is mounted on an
8200 tape drive, ready it by pressing the START button,
and continue with step 8
** The step numbers will change. The steps 10 to 17 in this
MTB replace steps 10 to 15 in the current manual.
10. If booting from an IOM then continue with step 11. If
MTB-737 Dipper Documentation
booting from an IMU continue with step 15
** Add 1 (one) to the next step numbers as the currently
appear in the manual.
11. If the buttons on your bootload console are wired to the
INITIALIZE and BOOTLOAD functions in the IOM, continue
with step 12 (for a 6601) or step 13 (for a 6001/6004).
Otherwise continue with step 14.
12. If the bootload console is a 6601 and you have a system
indicator panel next to the console, do the Following:
o press the INITIALIZE button (located on the panel)
o wait for the DATA SET READY light to blink
o press the RETURN key
o wait for the system to respond with:
CONSOLE READY...
o press the BOOTLOAD button (located on the panel).
If you don't have a system indicator panel at your site,
do the following:
o type ESC CTL-I (press the ESC key, then hold down the
CTL key while you press the I key)
o wait for the DATA SET READY light to blink
o press the RETURN key
o wait for the system to respond with:
CONSOLE READY...
o type ESC CTL-B (press the ESC key, then hold down the
CTL key while you press the B key).
Then continue with step 16
13. If the bootload console is a 6001/6004, do the following:
o press the INITIATE button (located on the console
cabinet).
o press the BOOTLOAD button (located on the console
cabinet).
Then continue with step 16
Dipper Documentation MTB-737
14. Go to the bootload IOM. Press the SYSTEM INITIALIZE
(L68)/SYSTEM INIT (DPS 8) button on the bootload panel.
Then press the BOOTLOAD button, also on the bootload
panel. Then continue with step 16.
15. There are three ways to bootload the system using the IMU.
The example assumes the bootload IMU is 1 and the MCA
number is 01. The ">" character is printed by the MCA/MDI
interface and not by you.
A. If the system indicator panel buttons are wired to the
INITIALIZE and BOOTLOAD functions then do the following:
o press the INITIALIZE button (located on the panel)
o wait for the system to respond with:
You will see the following on the VIP only:
#---------- Console Self-Test in Execution ----------#
#----- Control Terminal Display Check, Completed. ----#
The following will be displayed on both the VIP and hard
copy printer:
# CONSOLE SELF TEST SUCCESSFUL #
# COPYRIGHT 1983,84 (C) HONEYWELL INFORMATION SYSTEMS #
# IPC CONSOLE READY (F/W TAB 008) #
# MULTIDROP ENABLED #
#01<
#01<MSG MCA IMU INITIALIZE STARTED CONFIG FILE: .CXXXX
#01<
#01<MSG MCA INITIALIZATION COMPLETE: NO ERROR
#01<
#01<
#01<Monday September 23, 1985. 09/23/85 (03:11:30)
o press the BOOTLOAD button (located on the panel)
o wait for the system to respond with:
#01<
#01<MSG MCA SYSTEM BOOT IN PROGRESS
#01<
Then continue with step 16
B. If MCA input is enabled do the following:
o type #01>iboot
MTB-737 Dipper Documentation
o wait for the system to respond with:
You will see the following on the VIP only:
#---------- Console Self-Test in Execution ----------#
#----- Control Terminal Display Check, Completed. ----#
The following will be displayed on both the VIP and hard
copy printer:
# CONSOLE SELF TEST SUCCESSFUL #
# COPYRIGHT 1983,84 (C) HONEYWELL INFORMATION SYSTEMS #
# IPC CONSOLE READY (F/W TAB 008) #
# MULTIDROP ENABLED #
#01<
#01<MSG MCA IMU INITIALIZE STARTED CONFIG FILE: .CXXXX
#01<
#01<MSG MCA INITIALIZATION COMPLETE: NO ERROR
#01<
#01<
#01<Monday September 23, 1985. 09/23/85 (03:11:30)
#01<
#01<MSG MCA SYSTEM BOOT IN PROGRESS
#01<
Then continue with step 16
C. If the MCA/MDI input is locked then do the following:
o type ESC CTL-I (press the ESC key, then hold down the
CTL key while you press the I key)
o wait for the system to respond with:
You will see the following on the VIP only:
#---------- Console Self-Test in Execution ----------#
#----- Control Terminal Display Check, Completed. ----#
The following will be displayed on both the VIP and hard
copy printer:
# CONSOLE SELF TEST SUCCESSFUL #
# COPYRIGHT 1983,84 (C) HONEYWELL INFORMATION SYSTEMS #
# IPC CONSOLE READY (F/W TAB 008) #
# MULTIDROP ENABLED #
#01<
#01<MSG MCA IMU INITIALIZE STARTED CONFIG FILE: .CXXXX
#01<
#01<MSG MCA INITIALIZATION COMPLETE: NO ERROR
Dipper Documentation MTB-737
#01<
#01<
#01<Monday September 23, 1985. 09/23/85 (03:11:30)
o type ESC CTL-B (press the ESC key, then hold down the
CTL key while you press the B key).
o wait for the system to respond with:
#01<
#01<MSG MCA SYSTEM BOOT IN PROGRESS
#01<
Then continue with step 16
16. The BCE/Multics tape will move, and if the tape drive has
a BOT light it will go out. In addition, the audible
alarm on the bootload console will sound. Press
ATTN/RESET (6001/6004) or any key (6601) to turn it off.
17. The system will respond on the bootload console with:
** A new "Booting System ..." message will be supplied.
Enter boot tape MPC model:
If the bootload tape subsystem controlled by an MPC, then
continue with 18. Otherwise there is no firmware to load,
and to indicate this type:
ipc
Wait for the system response of:
Enter rpv data:
Then continue with step 20, "Entering the Location of the
RPV.
If the bootload tape subsystem is controlled by an MPC
Then continue with the following steps.
** Step 17 was step 15. Change step number 16 to 18, and step
number 17 to 19. The next set of data starts on page 11-5
after the current step 17 (new step number 19).
Entering the Location of the RPV
In the two steps which follow, the disk controller in
question is the one for the bootload disk subsystem. The
bootload subsystem is the one that contains the disk pack that
houses the Root Physical Volume (RPV).
MTB-737 Dipper Documentation
20. If the disk pack that houses the RPV is a MSU3380 or a
MSU3390 then continue with step 21. If not continue with
this step.
** Continue the info in this step with the data in the current
step 18. At the end of this step add:
Then continue with step 22.
** After this step add the new step 21.
21. At the bootload console, type:
rpv < IOM designation > ipc < disk drive model >
< disk drive number and subvolume >
for example:
rpv a20 ipc 3390 0a
where "a" is the tag of the IMU in which the disk ipc is
located, "20" is the number of the IMU ipc channel. The
"ipc" is the designation for the IPC-FIPS disk channel in
the IMU for these disk types. The "3390" is the model of
the disk drive. The argument "0a" indicates that the RPV
is located on disk drive "0" and subvolume "a" of the disk
pack is the RPV physical volume.
** The documentation changes necessary for the rest of the
booting sequence are:
1. Add 3 to each remaining step numbers.
2. Change the step number references in each remaining steps
to the new step number.
** Add to the end of the first paragraph under "Initializing BCE"
(page 11-9).
If the tape is mounted on a 8205, 8206, 8208 device then press
the RESET button, then the LOAD/REWIND button. This will
insure that the tape is at BOT. Then ready the device by
pressing the START button.
** Change step 1 under Initializing BCE (page 11-9).
1. Sometimes the BCE/Multics tape and tape drive don't operate
correctly on the first attempt. If nothing happens after
you attempt to boot the system by pushing the INITIALIZE and
BOOT, or the IBOOT command for IMUs, try the sequence at
least three more times before trying something else.
Dipper Documentation MTB-737
** Change step 2 under Initializing BCE (page 11-9).
2. If nothing happens after you have tried the booting sequence
three times, and the tape subsystem is on a MPC, check the
tape MPC switches to make sure they reflect the correct
BCE/Multics tape drive, MPC link adapter, and BCE/Multics
tape density. If they don't start over at step 2. If the
tape is on an 8200 or the tape subsystem is on an IMU,
verify the tape is on the device defined in the MCA config
file. The default tape device can be changed by adding the
"dxx" argument to the iboot MCA command. Where "xx" is the
new device number. Start over with step 14 using iboot dxx.
** Change step 4 under Initializing BCE (page 11-9).
If the SOURCE (L68) / BOOT SOURCE (DPS8) switch is OK, or the
device is the same as the MCA config file (IMU), try
mounting the BCE/Multics tape on another tape drive, and
repeating steps 2 through 16. If your site has multiple
copies of the current BCE/Multics tape, you can also try
another tape and repeat steps 1 through %COMM%
Note: If booting from an IMU and the default device number
is changed by using the iboot dxx command the "xx" becomes
the default bootstrap device.
** Delete the discussion "TO BOOT BCE FROM BOS" (Page 11-12).
Editing The Config Deck to Change Hardware states
** Delete all references to BOS by removing the "TO CHANGE
HARDWARE STATES IN BOS" discussion (page 12-1,12-5).
Bringing the System Up
** Delete all references to BOS by removing the BOOTING BOS, BCE,
AND MULTICS" example (page 16-1, 16-3).
Managing User I/O Disk
** Add on page 20-3 end of step 10.
If the device is a MSU3380 or MSU3390 the system may display a
combination of these messages, one for each physical volume
label on the device.
MTB-737 Dipper Documentation
** Add on page 20-3 as part of step 12.
If a combination of authentication messages are printed. The
priority of the authentication responses is: "ss", "io",
"urg", and then "urd".
Managing Storage System Disks
** In the example of the disk name add and explain the optional
subvolume character at the end of the device name. Explain
that this is used to define the correct area of the device if
the device is of the type that is divided into subvolumes and
the command addresses a physical volume and not a logical
volume nor an entire device (page 21-1). In the examples
change "<disk pack>" to "<pv name>".
Doing Dynamic Reconfiguration
** Change the "TO ADD AN IOM" to "TO ADD AN IO Mainframe" (page
32-4). Also indicate that there are two types of IO mainframes
defined via the same type card. The rcf command does not
change.
TO ADD AN IO MAINFRAME
Note:
There are two types of IO mainframes used on Multics
systems, IOMs and IMUs. These are both defined by iom cards.
1. If the IO Mainframe to be added is an IOM the first thing
you should do is make sure that all of the switches on the
IOM are set correctly, in the usual way. Refer to Section 9
and Appendix A. If the IO Mainframe is an IMU you should
know if the default IMU internal configuration file is to be
used or one of the other configuration files, and that the
correct diskette is in one of the IMU disk drives. These
internal configuration files set the hardware configuration
on the IMU.
2. If the IO Mainframe is an IMU DO NOT USE the MCA command of
INIT, this will initialize the entire system. The MCA
command of "RLOAD IMU" should be used. Refer to the
"Information Multiplexer Unit Hardware Operations Manual".
If adding an IOM type IO Mainframe then the IOM must be
initialized before it can be added to the system. To
initialize a Level 68 IOM, go to the maintenance panel. Set
the IOM INIALIZE switch to MANUAL and press the MANUAL
Dipper Documentation MTB-737
button. (DO NOT confuse this with the the SYSTEM INITIALIZE
button on the bootload panel.) To initialize a DPS ( IOM,
go to the configuration panel. Press the INITIALIZE button.
(DO NOT confuse this button with the SYSTEM INIT button on
the bootload panel.)
Dipper Documentation MTB-737
6 MULTICS SYSTEM ADMINISTRATION PROCEDURES (AK50-03)
Hardware Overview
** Change the heading "Input/Output Multiplexer (IOM)" to "IO
Mainframes". Add the info for the IMU (page 3-2).
IO Mainframes manage all of the peripherals connected to the
system. Peripherals include the bootload console, terminal,
storage devices, unit record devices, FNPs, and miscellaneous
other devices. Storage devices and unit record devices are
connected to controllers, which are in turn connected to the IO
Mainframes. Managing the peripherals means that the IO
Mainframes handle all transfer of data between them and memory.
To help with the transfer of data the IO Mainframes use
"channels" located inside the IO Mainframe cabinet. A
"channel" is a connection between an IO Mainframe and an FNP,
controller, or a console, over which the system can do I/O.
The configuration deck specifies what channels exist and to
what they are connected.
There are two types of IO Mainframes used on the system, the
Information Multiplexer Unit (IMU), and the Input/Output
Multiplexer (IOM). The IMU is a newer style IO Mainframe
controlled by micro-processors, while the IOMs are "hardwired
controlled". The channels in the IOMs are simply called "IOM
channels". The channels in the IMU are Integrated Peripheral
Controllers, some are micro-processor controlled. There are
two kinds of IOMs: the Level 68 and the DPS 8. The primary
difference between the IOMs is that on the DPS 8, certain
switches and lights have been replaced with displays, (See "DPS
8 vs Level 68" later in this section.) There can be up to 4 IO
Mainframes in a Multics configuration, and the types can be
intermixed.
** In the remaining topics "IOM" should be replaced with "IO
Mainframe".
** In the block diagrams in the section it should be shown that
the blocks labeled IOM or INPUT/OUTPUT MULTIPLEXER may also be
an IMU.
** Under the topic "DISKS" MPC should be changed to disk
controller (page 3-3).
** Under the topic "TAPES" MPC should be changed to tape
controller (page 3-3)
MTB-737 Dipper Documentation
** Add subvolume page (page 5-6).
subvolume
A portion of a large disk pack that contains one physical
volume. Only the MSU3380s and MSU3390s are divided into
subvolumes.
** Add the 3380, and 3390s delete 181. Also add 8205, 8206, and
8208 tapes. (page 9-7)
Understanding Reserved Attribute Names
The following attributes are mandatory for devices named,
and must appear in all RTMFs:
For the disk_drive device:
model=400 model=451 model=191
model=500 model=402 model=3380
model=3390
For the tape_drive device:
track=7 track=9 den=200
den=556 den=800 den=1600
den=6250 model=400 model=500
model=600 model=610 model=8200
Disk Volume Registration
** Add info for subvolumes in the "Understanding" paragraph.
(page 14-1)
Understanding Physical and Logical Volumes
Disk packs are the principal means of storing information on
Multics. The hardware disk packs contain the physical volumes,
for most devices the entire disk pack is the physical volume.
The 3380 and 3390 devices contain more then one physical
volume, called subvolumes. Each subvolume is a complete and
independent physical volume as seen by the storage system. The
Multics system permits the grouping of physical volumes into
sets, with each set considered a single unit. These grouping
are independent of the device type that contains the physical
volumes. The group of physical volumes joined together in the
set are considered a single volume.