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.