SECTION SRB
SIGNIFICANT CHANGES IN THIS RELEASE
This release contains the first installation of Bootload
Multics, also known as the Bootload Command Environment (bce).
Bootload Multics is a new phase of Multics initialization. It
allows the operation of Multics with or without BOS. The ability
to "warm" boot Multics from disk is provided by Bootload Multics;
that is, to boot without the MST mounted on a tape drive.
Bootload Multics provides a new ring zero command level.
The functions of warm booting, dumping and examining memory, and
emergency shutdown are performed from this command level. These
functions may no longer be performed from BOS. Also, automatic
operation is driven from the Bootload Multics command level. The
BOS functions of SAVE/RESTOR, SAVE COPY, CORE SAVE/RESTOR, as
well as a few specialized functions, are not yet available.
Also, printer support is not yet available.
The operation of Bootload Multics is described in detail in
Section 5.5 of the Multics Operator's Handbook, Order Number
AM81. This material must be read prior to attempting a boot of
this release. The presence of Bootload Multics will have no
effect on any user's process or application.
Bootload Multics requires 2455 pages of disk space on the
rpv for its operation, split between the new "bce" and "file"
partitions. These partitions will be automatically created when
this release is booted for the first time; the site, however,
must assure that a sufficient amount of space on the rpv exists.
For a better discussion of the changes involved with
Bootload Multics, refer to Appendix X of this SRB.
This release provides the ability of site maintenance
personal to set "probe" breakpoints in hardcore. When a
breakpoint is encountered, Bootload Multics will be invoked to
allow the analysis of the machine conditions. The breakpoint
conditions may be modified and then Multics restarted.
SRB-1
SECTION SRB-X
BOOTLOAD MULTICS (BCE)
MR11 includes a new phase to initialization known
alternately as Bootload Multics or the Bootload Command
Environment (bce). This release provides the first installment
of bce; future releases will provide further enhancements. The
goal of bce is to allow Multics to be operated without BOS. This
installation provides the basic facilities that a site must have
to run without BOS. Certain facilities present in BOS, used at
some sites, may not be present in this installation of bce; for
these facilities, the site will use BOS, just as in previous
releases.
The intent of this appendix is to describe bce in terms of
its difference from the previous method of operation (i.e. BOS).
This information should be used in conjunction with the
description of bce appearing in the MOH.
_T_H_E _M_S_T
bce, is not, as was BOS, on a separate tape from Multics.
Both bce and Multics originate on the same tape, the Multics
System Tape (MST). bce is an integral part of the Multics
initialization software. It both uses and is used by the Multics
initialization software.
bce/Multics may be booted from BOS or via the IOM boot
function. When booted from BOS, it is not necessary to load
firmware into the various controllers or set the system clocks
from bce, as this will already have been done from BOS. Also,
the configuration description needed by Multics is passed up from
BOS. When booted from the IOM, the firmware loading, clock
setting and config deck preparation are all done from bce.
Once booted, bce has no further use of the MST. Multics
service can be booted directly from bce without the aid of the
MST tape. This is because the needed contents of the MST tape
are saved in a partition of the rpv. This is an important
difference from the previous BOS method of operation. Note,
SRB-X-1
then, that an MST tape is not kept mounted on a tape drive during
periods of auto-reboot-mode operation.
_B_O_O_T_I_N_G
The equivalent of booting BOS is now to boot bce. Under
normal circumstances, bce is booted once within a given series of
boots of Multics service. It serves an equivalent function to
BOS in that it forms a platform from which Multics is booted and
to which Multics crashes or shuts down.
The booting of bce has the same significance as did the
booting of BOS previously, even if bce is booted from BOS. That
is to say that Multics service, although grown from bce, is to be
considered as a separate entity from bce, just as Multics and BOS
were considered separate and distinct entities in the past. When
Multics crashes or shuts down, Multics, as an entity,
relinquishes control of the system; bce, as an entity, takes over
control. bce can then perform emergency shutdown and dumping of
Multics.
bce can be booted from BOS, if BOS will be needed later, or
bce can be booted alone. The actual sequences for booting bce
appear in the Installation Instructions and in the MOH.
The directive "boot" now has two possible meanings. When
used in BOS, it means to boot an MST, thus starting up bce. When
used at the bce "boot" (or "bce_crash") command level, it means
to boot Multics service.
The next two sections provide some comments on the new
booting procedures.
_B_o_o_t_i_n_g _b_c_e _f_r_o_m _B_O_S
When BOS is booted first, and bce is booted from BOS, BOS is
used for those hardware and configuration initialization
functions for which it has always been used. Once bce is booted
from BOS, though, BOS is out of the picture as far as system
operation is concerned. bce/Multics will not return to BOS under
any circumstances unless the operator so directs. For this and
even more fundamental reasons, certain functions, previously
performed by BOS, can no longer be performed at BOS. These
include ABS, BLAST, DUMP, ESD, FDUMP and PATCH.
The process of booting BOS, as well as BOS itself, must
perform certain initialization functions before booting bce.
These are listed below, in order as they are performed.
The IOM INITIALIZE/BOOT function is invoked. The FWLOAD
function of BOS is read into memory in the process.
SRB-X-2
The bootload tape MPC is loaded by answering the prompt,
"Enter tape controller type:".
The other MPCs (disk MPCs as well as other tape and unit
record controllers) are loaded by supplying their types
and channel addresses to the FWLOAD prompts.
BOS is booted (which is irrelevant as far as bce is
concerned).
The config deck is generated or corrected.
bce/Multics is booted.
The BOS BOOT function is used as before to boot the
bce/Multics tape. The booting of Multics will appear as it would
in the past. The only visible difference is that Multics stops
at a new command level it did not have before. This is the bce
(ring-0, if you wish) command level. The bce command level can
be detected by the presence of the bce ready message:
bce (boot) TIME:
The word "boot" is sometimes replaced by other names, depending
on the system state. These are discussed later.
For more details on booting bce from BOS, refer to the MOH.
The normal day-to-day functions previously performed by BOS
will now be performed at this bce command level. The function of
booting Multics service takes place from bce. Also, when Multics
crashes or shuts down, the system will return to bce, instead of
BOS, so that emergency shutdown and dumping can be performed.
_B_o_o_t_i_n_g _b_c_e _f_r_o_m _t_h_e _I_O_M
The IOM INITIALIZE/BOOT function can be used to boot bce.
In this case, all hardware and configuration initialization
functions previously performed by BOS are performed by bce
itself. In most cases, the system requests the performance of
these functions in the correct order. It might be worthwhile,
though, to describe the initialization functions that must be
performed, in order, during the process of booting bce. For more
details, refer to the MOH.
The IOM INITIALIZE/BOOT function is invoked. Collection 0
of bce will be read in as a result.
Firmware is loaded into the bootload tape controller. This
is done by answering the "Enter boot tape MPC model"
query.
SRB-X-3
The bootload disk controller is booted. This is done by
answering the query "Enter RPV data". This also
locates the RPV.
The config deck is generated or corrected. During a cold
boot, the config deck is generated by using the config
deck editor at the "bce (early) TIME:" prompt. For a
normal boot, the config deck is read from the rpv
specified in the previous step and brought up to date,
if necessary, by the config deck editor. When this is
done, enter "bce" to complete the booting of bce. (bce
is not fully booted until it reaches the "boot" state.)
The system clock is set. The time value is requested after
entering "bce" above.
All other disk mpcs are booted, if necessary. This is done
in the load_disk_mpc dialog.
All other controllers are booted. This is done with the
fwload (fw) command at the "bce (boot) TIME:" prompt.
Notice that the same initialization functions are performed
as were previously performed by BOS, but their order is
different. The only function that the operator must explicitly
remember to do is to load the other MPCs at the "bce (boot)
TIME:" prompt.
Once the other mpcs have been loaded, bce can be considered
fully initialized. At this point, the system will be sitting
with the prompt
bce (boot) TIME:
This prompt signifies that the system is at bce command level, a
new (ring-0) command level. In the course of booting Multics,
this may be simply viewed as another command level (along with
the ring-1 and ring-4 command levels) in the process of booting.
However, this command level signifies that bce has control with
the same significance as we used to say that BOS has control in
the past. The function of booting Multics service takes place
from this command level (bce "boot" command level).
_N_O_R_M_A_L _O_P_E_R_A_T_I_O_N _O_F _B_C_E
The types of operations to be performed from bce are a
subset of those previously performed at BOS. (Eventually all
functions BOS performed will be performable from bce.) These
operations include booting Multics service, taking dumps of a
crashed Multics system, and invoking emergency shutdown of
Multics. The commands to perform these basic operations are
SRB-X-4
similar in operation and appearance to their BOS counterparts.
In particular, these equivalences are:
BOOT -> boot
ESD -> esd
FDUMP SHORT -> dump -short
etc.
The invoking of the standard BOS runcoms is replaced by invoking
the corresponding bce exec_coms. Thus:
AUTO -> ec auto star
GOGO -> ec go
RTB -> ec rtb
Other than these standard operations, the commands within
bce differ considerably from BOS. The MOH should be consulted
for the operations of these commands.
The MOH lists the functions currently performed by bce.
Certain other functions such as SAVE/RESTOR must still be
performed from BOS. If such operations are desired (those
performable by BOS but not yet performable by bce), it is
necessary to return to BOS. If bce was booted from BOS, simply
use the bce "bos" request. The BOS GO request will restart bce
where it was. If bce was not booted from BOS, it will be
necessary to boot BOS. Boot BOS only after successfully shutting
down Multics service.
_S_T_A_T_E _O_F _T_H_E _S_Y_S_T_E_M
bce can be in various states. The state of bce can be found
from the bce ready message/prompt:
bce (STATE) TIME:
It also can be found within bce via the bce_state request/active
function.
The "early" state normally appears only once, when booting
bce initially. When bce is in this state, the purpose is to have
the operator generate or correct the config deck, followed by
setting the clock when the system leaves this state (by entering
"bce").
The "boot" state is the normal state of bce. In this state,
Multics service may be booted.
If bce should fail, the "bce_crash" state is entered. When
this occurs, the dying bce is saved and can be dumped (if this is
desired). From the "bce_crash" state, one can enter
"reinitialize" to return to the "boot" state from which one can
SRB-X-5
then boot Multics service. As a short cut, Multics service can
be booted directly from the "bce_crash" state by entering "boot";
this performs a reinitialize and a boot of Multics service
without stopping at the bce "boot" command level.
When Multics crashes, bce is in the "crash" state. This
state exists just so that the operator is reminded that a dead
Multics exists which should be dumped and shut down (esd).
_T_H_E _T_O_E_H_O_L_D _A_N_D _'_E_X_E_C_U_T_I_N_G _S_W_I_T_C_H_E_S_'
BOS has a toehold. The toehold is a small program that was
the main driver when switching between Multics and BOS. It also
held the communication flags between BOS and Multics (the
flagbox). The toehold is located in memory at absolute address
10000 (octal).
bce also has a toehold used in much the same way as the BOS
toehold.
Since the BOS toehold is being kept around for this release
(as the driver for switching between BOS and bce (when BOS is
used)), the bce toehold (used for switching between bce and
Multics) must be at a different location. The bce toehold is at
absolute location 24000 (octal).
Thus, "executing switches" to force a manual return to bce
uses a different switch value than does forcing a return to BOS.
This switch value is "024000717200". When "executing switches"
on a L68 processor, this is the value to enter into the data
switches.
Since the toehold address to crash Multics has changed, the DMP's BOS
command is no longer used. Instead, with FCO PHXXXXX the DMP will except the
BCE command with the octal switch value for the first argument. Foe example,
"BCE 024000717200" entered on the DMP will return the system to BCE level.
The system will warn the operator if the data switches on
any processor are not set to the above value.
_G_E_N_E_R_A_L _O_P_E_R_A_T_I_O_N _O_F _B_C_E
The operation of the bce command level differs both from the
old BOS command usage and the Initializer ring-1 and ring-4
command level usage. The syntax and usage of this bce command
level is much more that of standard Multics command level. (This
is described in the MPM Reference manual and will not be repeated
here.) In particular, active functions and command iteration are
used. exec_com's (version 1) are available. Normally, though,
SRB-X-6
commands are typed simply as a command name followed by a
collection of arguments, separated by spaces.
The commands within bce attempt to resemble their
counterparts (if any) within service Multics. For details of the
execution of any given command, refer to the MOH.
Some things to remember about bce operation follows.
The text editor used to edit bce files (equivalent of BOS
runcoms) is qedx. It bears no resemblance to the BOS EDIT
command. The description of qedx appears in the manual, Commands
and Active Functions. The version of qedx within bce differs
from the standard version in that there is a query if one tries
to exit qedx with unwritten modified buffers.
Config decks are edited with the config_edit (config)
request. The config command in bce bears absolutely no
resemblance to the CONFIG command in BOS. One must remember when
one is in the config deck editor that one is really in qedx.
The bce equivalent of BOS runcoms is version 1 exec_coms.
These have absolutely no resemblance to BOS runcoms. An
important thing to remember when converting BOS runcoms to bce
exec_coms is that, when a BOS runcom invokes another runcom, that
second runcom will never return to the first. In bce, an
exec_com will return to its invoking exec_com. Also, a BOS
runcom that boots service regains control when Multics crashes or
shuts down. In bce, the invoking exec_com (and all exec_coms
which invoked the exec_com that booted service) lose control
whenever a "boot", "esd" or "go" operation are performed. The
exec_com that bce invokes whenever Multics crashes or shuts down
is determined solely by the "bce_command" flagbox variable. It
is this variable (and other flagbox flags) that are manipulated
by the auto exec_com procedures.
Within BOS, functions were aborted by hitting RETURN or EOM
on the operator's console. There was no way to indicate that
this was an accident. Within bce, hitting RETURN or EOM allows
the operator to indicate the intention to abort a function. When
this occurs, the system will ask "Abort?" to which the operator
may answer "no" or "yes" appropriately to abort the current
operation. Other responses are allowed; refer to the MOH for
more details.
SRB-X-7
SECTION II-4
INSTRUCTIONS FOR SITES UPDATING FROM PREVIOUS RELEASE
_S_T_E_P_-_1
II-4-4
SECTION II-5
INSTRUCTIONS FOR SITES INSTALLING FOR THE FIRST TIME
_S_T_E_P_-_3
Mount the Multics System Tape (MST) on Magnetic Tape Handler
(MTH) nn (nn is usually equal to 01). Mount the disk pack
formatted by T&D on the drive selected to be the RPV. Initialize
and boot the MST. Multics will prompt with:
bootload_0: Booting system MR11 generated 11/01/84 0000.0
est Thu.
bootload_0: Enter boot tape MPC model: t500
Normal response to this question should be "t610", "t601", "t500"
or "ipc". The system will boot the bootload tape controller, if
necessary, and continue. At this time, the intention to cold
boot is given. Multics will request the location of the rpv.
Once this is done, the init_vol request loop will be entered to
accept the layout of the rpv.
bootload_0: Booting t500 A 12. with mtc500 rev.u1
firmware.
bootload_0: Booted tape MPC.
0000.1 announce_chwm: 347. pages used of 512. in wired
environment.
0000.2 announce_chwm: 620. words used of 1024. in
int_unpaged_page_tables.
Enter RPV data: query
Enter RPV subsystem base channel, as Icc, or "cold". cold
Booting cold will destroy all data on the RPV.
Are you sure that you want to boot cold? yes
Enter RPV subsystem base channel, as Icc. A22
find_rpv_subsystem: Enter RPV subsystem MPC model: 609
hc_load_mpc: Booting channel A22 with dsc500 Revision j1.
find_rpv_subsystem: Enter RPV disk drive model: 451
find_rpv_subsystem: Enter RPV drive device number: 1
find_rpv_subsystem: RPV is a model 451 drive, number 1 on
MPC A22, and this is a COLD boot.
Is this correct? yes
II-5-1
Default RPV layout: (Respond "end" to use it.)
Average seg length = 2.00
VTOC size = 2792 pages, 13920 vtoces.
27840 paging records.
Constrained by average seg length.
part hc 2792. 2500.
part conf 5292. 4.
part alt 38117. 141.
part bos 37847. 270.
part dump 35847. 2000.
part log 35591. 256.
part file 35336. 255.
part bce 33136. 2200.
These are the default partition assignments. Any changes to the
default partitions or RPV parameters can be redefined by using
the "startover" request in init_vol. The system installer should
review the write-up of init_vol in the MOH prior to the
installation.
Sizes for the various partitions and their locations can be
modified based on the needs of the site.
request: end
init_empty_root: Begin rpv initialization. This will take
some time.
init_empty_root: rpv initialized; 27840 records.
0007.0 find_file_partition: Initializing file partition.
Data not in expected format.
0010.0 load_mst: 627. out of 1048. pages used in disk mst
area.
bce (early) 0010.2:
Build the configuration description as follows:
config
a
.
. (Configuration fields as defined in the MOH.)
.
\f
w
q
Do not enter any part cards at this time, except for those
partitions defined on the rpv. Also, make the root card specify
only the rpv.
Continue booting bce.
II-5-2
bce (early) 0020.0: bce
Current system time is: 01/01/01 0020.1 est Tue.
Is this correct? no
Enter time: 84-11-02 12:00
Current system time is: 11/02/84 1200.0 est Fri.
Is this correct? yes
load_disk_mpcs: Disk mpcs mpca mpcc appear not to be
operating.
Enter disk mpc names to be loaded,
or "none" or "abort" or "all": mpca mpcc
(The operator entered the names of other disk mpcs
to be loaded.)
hc_load_mpc: Booting channel A20 with dsc500 Revision j1.
hc_load_mpc: Booting channel B20 with dsc500 Revision j1.
bce (boot) 1200.5:
At this time, the operator must load firmware into all other
controllers (i.e., not the bootload tape controller nor any disk
controllers). bce is then considered to be fully initialized.
bce (boot) 1200.5 : boot -cold
Do you really wish to boot cold? yes
hdx: reregistered public lv root lvid 727353262340
hdx: Entry is not a branch. cannot make mdcs in lv root
hdx: reregistered pv rpv pvid 727353262301 in lv root
disk_table_: New disk_table created.
Multics MR11 - 11/02/84 1201.0 est Fri.
Ignore the messages prefaced by disk_table_ and hdx.
II-5-3
SECTION HSF-7
MULTICS ENVIRONMENT
Changes to Hardware and Software Formats PLM:
The changes to the Hardware Software Formats PLM are
obviously enough all in the software section, Section 7, "Multics
Environment." Other sections in this manual are incorrect and
out of date but corrections to them do not appear here.
_M_A_I_N _M_E_M_O_R_Y _M_A_P_S
The following paragraphs describe the gross allocation of
main memory during the three distinctly different Multics
operational environments: BOS, bce and service.
In the address charts that follow, the addresses are
absolute octal memory addresses. Whenever an address appears in
brackets ([]), this means that the object described is contained
within the segment listed above it.
_C_o_m_m_o_n _A_r_e_a_s
Certain areas are common between the three modes of
operation; these areas are dictated mostly by hardware
requirements.
FAULT_VECTOR
The fault_vector area holds vectors and its pointers used
for handling interrupts and faults. This area is described
below.
address
HSF-7-1
000000 interrupt vectors
contains interrupt pairs, each containing a scu/tra
pair specifying absolute addressing. The target of the
addresses is in the "its" area.
000100 fault vectors
contains fault pairs, one for each defined fault, each
containing a scu/tra pair specifying absolute
addressing. The target of the addresses is in the
"its" area.
000200 its pointers for fault and interrupt vectors
contains the its pointers that are the targets of the
scu and tra instructions above. Only these its
pointers are normally changed; the scu and tra
instructions remain.
MAILBOXES
The mailbox area holds control areas used to converse with
the ioms and the fnps.
address
001200 IOM imw area
is used to determine which channel of the iom generated
an interrupt.
001400 IOM A mailbox
002000 IOM B mailbox
002400 IOM C mailbox
003000 IOM D mailbox
003400 FNP A mailbox
003700 FNP B mailbox
004200 FNP C mailbox
004500 FNP D mailbox
005000 FNP E mailbox
005300 FNP F mailbox
005600 FNP G mailbox
006100 FNP H mailbox
_B_O_S _E_n_v_i_r_o_n_m_e_n_t
BOS operates in segmented, nonpaged appending mode with
exactly eight defined segments. The eight pointer registers are
loaded with fixed segment numbers and the segment base and bound
values are manipulated according to the requirements of the code.
HSF-7-2
address
000000 fault_vector
000600 padding
001200 mailbox area
006400 padding
007740 ds (descriptor segment)
010000 toehold (BOS)
[010020] flagbox (BOS)
011000 setup
020000 bf (buffer)
022000 com (common variable storage)
031000 pgm (program area)
040000 util (utilities)
060000 rest of BOS memory, unused
The standard pointer register/segment assignments for BOS
are:
pr0 -> ds
pr1 -> pgm
pr2 -> bf
pr3 -> setup
pr4 -> (prog temporary)
pr5 -> flagbox
pr6 -> com
pr7 -> mem (first 256k of mem)
_b_c_e _E_n_v_i_r_o_n_m_e_n_t
The memory layout after the running of collection 0 (the
loading of collection 1, i.e. bce) follows. All segments are
paged with the exception of fault_vector, iom_mailbox and
dn355_mailbox.
address
000000 fault_vector
000600 padding
001200 iom_mailbox
003400 dn355_mailbox
006400 padding
HSF-7-3
010000 bos_toehold
012000 config_deck
024000 bound_bootload_0
[024000] toehold (bootload Multics)
[024000] flagbox (bootload Multics)
[030000] bootload_early_dump
046000 toehold_data
052000 unpaged_page_tables
054000 int_unpaged_page_tables
056000 breakpoint_page
060000 physical_record_buffer
066000 dseg
070000 name_table
100000 slt
104000 lot
106000 wired segments, fabricated segments, all other segments
_S_e_r_v_i_c_e _E_n_v_i_r_o_n_m_e_n_t
The memory layout after the running of make_segs_paged,
collect_free_core and the deletion of init and temp segs is as
follows. All segments are paged except for fault_vector,
iom_mailbox and dn355_mailbox.
address
000000 fault_vector
000600 padding
001200 iom_mailbox
003400 dn355_mailbox
006400 padding
010000 bos_toehold
012000 config_deck
024000 toehold (bootload Multics)
[024000] flagbox (bootload Multics)
030000 paging use
046000 toehold_data
052000 unpaged_page_tables
054000 paging use
056000 breakpoint_page
060000 paging use
HSF-7-4
106000 wired segments, fabricated segments, paging use.
sst_seg is located at the high end of the bootload
memory.
HSF-7-5
SECTION MOH
MULTICS OPERATOR'S HANDBOOK
Global directives:
Change all references to the BOS console, iom, cpu and scu to
refer to the bootload console, iom, cpu and scu.
Change all references to configuration cards to be in lower case
to emphasize that they should be in lower case.
Specific directives follow.
MOH-1
SECTION MOH-1
OPERATOR RESPONSIBILITIES
Change the paragraph describing the responsibility of the
operator to understand BOS to:
The operators must also understand the functions of the
bootload operating system (BOS) and the bootload command
environment (bce), which load Multics and perform various system
software maintenance activities. BOS controls the bootloading of
bce and can provide one type of save of the contents of the
storage system. bce controls the bootloading of Multics service
as well as performing memory dumps. Initially, BOS is contained
on a tape and must be bootloaded from the console into the
system. If a copy of BOS already exists on disk, it can be "warm
booted", preserving the contents of the disk that already
contains BOS. If there is no disk copy of BOS, it must be "cold
booted". bce makes up the first part of the Multics tape and is
usually bootloaded from BOS. bce can be booted from the console,
if necessary, without using BOS but then it cannot utilize the
BOS functions.
Acronym list
bce bootload command environment
_G_L_O_S_S_A_R_Y _O_F _T_E_R_M_S
bce
the bootload command environment; a set of programs within
Multics initialization that perform functions such as
bootloading Multics, dumping main memory and initiating
emergency shutdown of Multics.
bootload
to load a fresh copy of a set of programs. BOS, bce and
Multics can be bootloaded. Bootloads of BOS are "cold" if
they completely re-create BOS' operating environment and
MOH-1-1
"warm" if they assume that some information from previous
bootloads is to be used. Bootloads of bce and Multics are
"cold" if they re-create the file system, "cool" if they
maintain the file system but completely re-create bce's
operating environment and "warm" if they assume that some
information from previous bootloads is used. The period of
time between Multics bootload and shutdown is also spoken of
as a bootload, or service session.
BOS
the bootload operating system; a set of programs that
perform functions such as loading bce and dumping disks.
initializer process
change the reference to BOS to refer to bce
MOH-1-2
SECTION MOH-3
CONFIGURATION
_C_A_L_E_N_D_A_R _C_L_O_C_K
... The BOS time command, or the bce invoked clock setting
function, if BOS is not used, is used to set the clock for the
4MW SCU ...
... if the setting is inaccurate. Use the BOS TIME command, if
BOS is used, and the "clok" config card to check for inaccuracies
in the clock setting.
... For further information, refer to the BOS TIME command in
Section 5 and the bootload sequence in Section 5.5.
change:
_O_b_t_a_i_n_i_n_g _N_u_m_b_e_r _t_o _S_e_t _C_a_l_e_n_d_a_r _C_l_o_c_k
and what follows in the clock setting section to:
_S_e_t_t_i_n_g _C_a_l_e_n_d_a_r _C_l_o_c_k _i_n _4_M_W _S_y_s_t_e_m _C_o_n_t_r_o_l_l_e_r _U_n_i_t _w_i_t_h _B_O_S
1. At the operator console, enter BOS (if not already in
BOS). Make sure the "clok" card is loaded in the
configuration deck, and always type in the time in
local time as indicated on the "clok" card. Issue the
TIME command to BOS.
2. Type the date and time (according to your local time
zone) as follows:
MM DD YY hh mm ss
where:
MOH-3-1
MM is the month
DD is the day
YY is the year
hh is the hour
mm is the minute
ss is the second
When the date and time are typed, press EOM. The
seconds figure can be omitted; if it is, a value of
zero seconds is assumed. Choose a figure that is
slightly (a minute or less) in advance of the current
time, to allow time for the next step to be performed.
3. S is entered on the operator console and EOM is pressed
at the instant when the current time reaches the time
that was typed.
4. R is entered and EOM is pressed to read back the time
to verify correctness.
5. EOM is pressed to exit from the TIME command.
_S_e_t_t_i_n_g _C_a_l_e_n_d_a_r _C_l_o_c_k _i_n _6_0_0_0 _S_y_s_t_e_m _C_o_n_t_r_o_l_l_e_r _w_i_t_h _B_O_S
1. Type: TIME as above
2. Type: MM DD YY hh mm ss as above.
3. A series of numbers in the following form is returned:
NNNNN,NNNNNN NNNNNN TTTTTT TTTTTT MM/DD/YY HH::MM::SS.S
where TTTTTT TTTTTT is the number to be entered in the
switches on the 6000 SC maintenance panel in step 5
below.
4. At the CPU, the STEP CONTROL selector switch on the
maintenance panel is placed in the MEM position.
5. At the SC (which must be in TEST mode), the number
TTTTTT TTTTTT is entered in the upper row of the DATA
switches. All zeroes are entered in the lower row of
the DATA switches.
6. The INITIALIZE and the LOAD CLOCK pushbuttons are
pressed simultaneously, at the instant when the current
time reaches the time that was typed.
7. The STEP CONTROL selector switch on the CPU is turned
to OFF and the STEP pushbutton is pressed.
MOH-3-2
8. R is entered and EOM is pressed to read the time from
the calendar clock and verify correctness.
9. EOM is pressed to exit from the TIME command.
_S_e_t_t_i_n_g _C_a_l_e_n_d_a_r _C_l_o_c_k _i_n _4_M_W _S_y_s_t_e_m _C_o_n_t_r_o_l_l_e_r _U_n_i_t _w_i_t_h_o_u_t _B_O_S
1. When BOS is not used, bce will automatically invoke a
clock setting function after leaving the "early" bce
command level. The operator must ensure that the
"clok" configuration card specifies the correct time
zone. All times entered are to be in local time.
2. The clock setting routine will start by asking a
question of the form:
The current system time is DATE TIME.
Is this correct?
to which the operator should respond accordingly. The
operator may respond with "abort" to return to the
"early" command level.
3. If the operator's answer to the above question is "no",
bce will prompt with:
Enter time:
to which the operator should provide the current local
time. Choose a figure that is slightly (a minute or
less) in advance of the current time, to allow time for
the next step to be performed.
4. After the time is entered, bce will re-prompt with:
The current system time is DATE TIME.
Is this correct?
If this is not correct, the operator should respond
with "no" or "abort" as above. If this is correct, the
operator should answer "yes", pressing EOM at the
instant when the current time reaches the time that was
typed. bce will then continue with its initialization.
_S_e_t_t_i_n_g _C_a_l_e_n_d_a_r _C_l_o_c_k _i_n _6_0_0_0 _S_y_s_t_e_m _C_o_n_t_r_o_l_l_e_r _w_i_t_h_o_u_t _B_O_S
1. After leaving the "early" bce command level, the bce
clock setting function will be invoked.
MOH-3-3
2. bce will ask the correctness of the current time, as
above.
3. The operator may reply "abort" or "yes" as above. If
the operator answers "no", the time will be requested.
It is entered as above. bce will then respond with:
SCU Switches (octal) TTTTTT TTTTTT
4. bce will prompt with:
Enter anything after the switches have been set.
at which time the operator should perform steps 4
though 7 of the BOS instructions. When this is
completed, the operator should enter "y".
5. bce will repeat the question in step 2. This should be
answered appropriately.
MOH-3-4
SECTION MOH-4
I/O DEVICE OPERATION
_U_S_E _O_F _T_H_E _O_P_E_R_A_T_O_R _C_O_N_S_O_L_E
The operator may use the operator console to issue Multics
initializer commands, commands to the daemons, standard Multics
commands, commands to bce when bce is in operation and BOS
commands when BOS is in operation.
MOH-4-1
SECTION MOH-5
BOOTLOAD OPERATING SYSTEM
_B_O_O_T_L_O_A_D _O_P_E_R_A_T_I_N_G _S_Y_S_T_E_M _D_E_S_C_R_I_P_T_I_O_N
remove the reference to initiating an emergency shutdown of
Multics
_S_u_m_m_a_r_y _o_f _B_O_S _c_o_m_m_a_n_d_s
remove ABS, BLAST, DUMP, ESD, FDUMP and PATCH
Name: BOOT
remove the command and keywords fields from the command and
description of their use. Remove the BOOT STAR example from the
notes.
MOH-5-1
SECTION MOH-5.5
BOOTLOAD COMMAND ENVIRONMENT (BCE)
Add a new section describing bce after the section
describing BOS as follows.
_B_C_E _D_E_S_C_R_I_P_T_I_O_N
The bootload command environment comprises a set of programs
for performing functions such as the bootloading of Multics
service, dumping and patching main memory and disks and
initiating an emergency shutdown of Multics service.
bce is contained within the first two collections of modules
on the Multics system tape; it consists of the following major
parts:
1. collection zero routines
a series of programs capable of loading the other bce
programs into memory; this series is also capable of loading
firmware into the bootload tape mpc, if necessary.
2. collection one initialization
a series of programs that are part of Multics initialization
proper that also initialize the bootload command
environment.
3. toehold program
a small program permanently residing in main memory at
absolute location 24000 (octal). It communicates closely
with bce and with service Multics to perform administrative
functions.
4. bootload command utilities
a series of programs to provide the bce command level.
5. bce command programs
a number of programs that perform the operator directed
functions of bce.
MOH-5.5-1
_C_O_N_F_I_G_U_R_A_T_I_O_N _R_E_Q_U_I_R_E_M_E_N_T_S
bce requires the operator console; standard Multics error
recovery is used, however, in case of the failure of the main
console.
bce uses 512k of contiguous low order memory. All of bce's
functions can be performed within this memory.
Two special regions of the rpv are used by bce. These two
special regions have locations recorded in the label of the rpv.
The first is the "file" partition, which contains a simple file
system used by bce to hold bce exec_coms and ascii sources of
configuration files. The second is the "bce" partition, used by
bce to hold the following:
a saved copy of memory used by service Multics when bce is
invoked upon a crash
bce itself and bce command programs
the programs needed to boot service Multics
_L_O_A_D_I_N_G _B_C_E
bce can be loaded in two ways, via BOS or via the operator's
console. When booted via the operator's console (performed if
BOS cannot run on the current hardware configuration), the
facilities of BOS cannot be used.
_L_o_a_d_i_n_g _b_c_e _f_r_o_m _B_O_S
bce can be booted from BOS very easily by entering:
BOOT drive_number
where drive_number is the number of a tape drive on the bootload
tape controller that holds a Multics system tape. The first
message should read:
Booting system SYS_ID generated TIME.
This may be followed by various informative messages, depending
on various parameters in the config deck. The entire Multics
system tape will be read in stages. After this, bce will prompt
with the ready message:
bce (boot) TIME:
MOH-5.5-2
You are now at the normal bce command level.
_L_o_a_d_i_n_g _b_c_e _f_r_o_m _t_h_e _o_p_e_r_a_t_o_r_'_s _c_o_n_s_o_l_e
bce is loaded from a Multics system tape into memory and
into the bce partition as follows:
1. Mount and ready the Multics system tape on a tape drive
appropriate for the density of the tape.
2. Set the tape MPC switches 5, 6, 7 and 8 to the number of the
tape drive on which the system tape is mounted. If the tape
MPC is not wired to be initialized when the INITIALIZE
button is pressed, it must be initialized at the MPC control
panel. The Honeywell field engineer can advise the operator
whether or not the MPC is wired to be initialized when the
INITIALIZE button is pressed (if the reset out line (RSO) is
grounded, then initialization is suppressed).
3. Make sure that the CARD/TAPE switch on the IOM is set to the
TAPE position and that the tape channel number is set
correctly in the IOM switches.
4. At the operator console, press the RESET CONSOLE button.
(This button may not be present on some console models.)
5. For all consoles except the CSU6601, press the INITIALIZE
and then the BOOTLOAD button.
For the CSU6601, after pressing the INITIALIZE button, press
the RETURN key on the keyboard. Wait for the console to
respond with "CONSOLE READY", and then press the BOOTLOAD
button. If the system indicator panel is not present, the
boot sequence from the keyboard is:
esc ctl I return esc ctl B
Alternatively, press the INITIALIZE button and then the
BOOTLOAD button on the IOM to which is attached the tape
MPC.
6. If all goes well, the message:
Booting system SYSID generated TIME.
will appear on the console with an alarm. This will be
followed by the query:
Enter boot tape MPC model:
MOH-5.5-3
This information is requested so that firmware may be loaded
into this MPC. If firmware should not be loaded (or the MPC
does not allow being so loaded), the operator should answer
with "ipc". An answer of "shut" will stop (crash)
initialization at this point. A question mark will list the
valid MPC model names. Otherwise, the MPC model name should
be entered. Acceptable names are:
t500
t601
t610
A message of the form:
Booting MODEL IOM CHANNEL with FWID REVISION firmware.
followed by
Booted tape MPC.
signals successful booting of the boot tape MPC.
7. bce will proceed through various initialization programs,
possibly producing various status messages. The first
collection will be read from the system tape into memory.
After this is done, bce will request the location of the
rpv:
Enter rpv data:
The operator may answer "shut" at this time to abort
booting, typing "help" will provide some explanation and
typing "?" will cause bce to prompt the operator for each
item of information separately. Otherwise, the question
should be answered as:
rpv Icc MPC_model DRIVE_model DRIVE_number
or
cold Icc MPC_model DRIVE_model DRIVE_number
where:
I
is the IOM number containing the base channel of
the MPC containing rpv
cc
is the channel number on the IOM of the MPC (in
decimal)
MOH-5.5-4
MPC_model
is the model of the disk mpc (in decimal). Valid
models are:
191 400 451 601 603 607 609 611 612
DRIVE_model
is the model number of the drive containing rpv
DRIVE_number
is the number assigned to the drive on the MPC
"cold" is specified only if this is a "cold" boot, that is,
one in which the Multics storage system is either
non-existent or has been destroyed.
When a satisfactory answer is entered, the mpc
described will have firmware loaded into it, if necessary.
Entering "skip" or "skip_load", by itself and before
entering "rpv" or "cold" will suppress this load.
If this is a cold boot, the init_vol loop (described in
Section 7, Initializer Commands) will be entered. At this
time, the attributes of the rpv must be entered.
8. If the previous is successful, bootload Multics will come to
the "early" command level. This command level allows a
subset of the normal bce commands to be entered. The ready
message at this time is:
bce (early) TIME:
The purpose of this command level is to insure that the
config deck (obtained from the "conf" partition on disk) is
good. If this is a cold boot, the config deck will need to
be entered at this time. (The commands to do all of this
are described below.) Reaching the "early" command level,
however, is only part of booting bce. To completely boot
bce, enter "bce".
9. bce will enter its clock setting phase. (See the
description of clock setting in Section 3, Configuration.)
10. Another initialization pass is then run to enable usage of
the peripherals described by the config deck. The various
disk mpcs so described will be tested to see if they appear
to be running. If any are not, the message:
load_disk_mpcs: Disk mpcs NAMES appear not to be
operating.
Enter disk mpc names to be loaded,
or "none" or "abort" or "all":
MOH-5.5-5
The operator is to enter the names (from the set displayed
as NAMES, above) of disk mpcs into which firmware is to be
loaded. The operator should continue to enter names (on
multiple lines, if desired), until all disk mpcs to be used
are loaded. If "abort" is entered, a return is made to the
"early" command level.
11. Initialization will then continue until normal bce command
level is reached, prompting with:
bce (boot) TIME:
The operator should load firmware into all other tape and
unit record controllers at this time, using the bce "fwload"
command. At this time, bce is fully initialized.
_E_r_r_o_r _R_e_c_o_v_e_r_y _D_u_r_i_n_g _b_c_e _B_o_o_t
Several attempts are made to allow for error recovery during
the boot process. The methods depend on the point within the
boot sequence. It is best to describe the recovery by describing
some aspects of the internal operation of the boot sequence.
When booted from the switches, bce will pass through
collection 0 initialization, whose objective is to read in
collection 1 (bce proper). A config deck is synthesized from the
knowledge of the hardware found during this pass and through
questions to the operator. A first pass is made through
collection 1 to find the rpv and to read in the config deck last
saved in the "conf" partition on disk. If an error should occur
before this point (most likely a hardware or software failure),
the early dump facility is invoked (see below). Otherwise, this
environment (memory and the synthesized config deck) is saved on
disk. The "early" command level is then entered. The operator
must then make sure the config deck (read from disk) is correct.
The operator then enters "bce" to actually boot bce.
Initialization continues with a second pass through collection 1.
If this pass fails (most likely either a hardware problem or an
error in the config deck), the saved environment will be restored
and the operator returned to the "early" command level. The
operator then retries the boot. Eventually this will succeed and
bce will come to the "boot" command level, having saved this new
environment and config deck.
When bce is booted from BOS, collection 0 is still run to
read in collection 1. In this case, though, the config deck need
not be synthesized; the config deck used by BOS is used. The
first pass through collection 1 will be the "boot" phase. If an
error should occur during this first pass, the early dump
facility will be invoked. BOS can be manually entered at this
time, if desired. If the pass is successful, this environment
MOH-5.5-6
(memory and the config deck) is saved to disk. The "boot"
command level is entered.
Once at the "boot" command level, the operator may perform
whatever bce functions are desired. "boot" is then entered to
boot Multics service. Another pass through collection 1 is made
to set up for Multics service. If an error occurs during this
pass (most likely hardware or a bad config deck), the environment
saved above is restored and the operator is returned to the
"bce_crash" command level. Also, if a bce utility should fail or
should encounter a breakpoint, this environment is restored and
"bce_crash" level entered. At this time, the operator may enter
"crash" level commands to examine the failed image (or to debug
bce), or "boot" level commands may be used to fix the config deck
(if necessary) and to retry the boot of Multics service.
An important thing to remember about coming to the
"bce_crash" or returning to the "early" command levels is that
they use an environment and config deck declared safe on a
previous initialization pass. As such, not all devices listed in
the "current" config deck (the one visible with the config deck
editor) may be accessible at this level. Generally speaking, to
access all devices, it is necessary for the config deck to be
correct and for an initialization pass (the "boot" pass) to be
made. If in doubt, entering "reinitialize" will run another
initialization pass.
Once the "service" pass of collection 1 completes, any
further failures of initialization or of Multics itself returns
to the "crash" command level, used for examining the crash. At
this time, the config deck as used by Multics is used. This is
done to take into account any reconfigurations performed by
Multics service. At the "crash" level, a dump should be taken
and an emergency shutdown performed.
_S_t_a_t_e_s _o_f _b_c_e
The previous sections described the various bce states,
"early", "boot", "bce_crash" and "crash". As an aid, the
relationship between these states will be shown through the
diagram below.
The lines marked with the letter "s" indicate the path
followed when an action is successful. The "c" lines indicate
when an action fails or a crash occurs in the given state. The
names in quotes are commands (or abbreviations of commands)
entered at the given commmand level.
MOH-5.5-7
IOM Boot/Init
s cccccccc
s c c
V c c
*********************** V
* early command level *<cccc
*********************** A
A s c c
c s-"bce"-c c
c s cccccc>c<ccccccccccccccccccccccccc<ccccccc
c V A c
c ssssssss>s<sssss<ssssssssssssss c c
c A s A s c c
c-"reinit"-s s s-"go" s-"reinit"-c c
c s V s s c c
********************** *************************** c
* boot command level *cccc>* bce_crash command level *cccc c
********************** *************************** c c
A s c A c s A c c
s s-"boot"-c c c-"boot"-s c c c
s s ccccc>c<ccccc s ccccccccc c
s s s c
s sssssssssssss>s<sssssssssssssss c
s V c
s ************* c
s * (service) *<sssss c
s ************* s c
s s c s c
s s-"shut" c s-"esd" c
ssssssssssssss<sss c s c
A c s-"go" c
s V s c
s *********************** c
s * crash command level * c
s *********************** c
s s c c
s s-"reinit"-c c
ssssssssssss cccccccccccccccccccccccc
_C_o_n_f_i_g _D_e_c_k _a_n_d _D_e_v_i_c_e _A_c_c_e_s_s_i_b_i_l_i_t_y
During Multics service, the set of devices that are
accessible (to the system as a whole) are precisely those
described by the config deck. The config deck is kept up to date
with the state of the devices. However, the real state of
devices and their accessibility is described by various control
tables within Multics. One of the main purposes of bootload
Multics is to set up these control tables. Since bootload
Multics allows arbitrary text editing upon the config deck, it
follows that the state of the control tables may not match that
MOH-5.5-8
of the config deck. This section describes some of these
subtleties.
When at "early" command level, the control tables describe
only those hardware units truly known, the bootload tape drive,
the rpv, the bootload processor, etc. At the "early" command
level, the operator is to make sure that the config deck
describes all hardware units. These units are not accessible at
this time, however.
Attempting a boot to "boot" command level builds control
tables describing all of these hardware units. If this boot
succeeds, all of these units are accessible from bootload
Multics. If it fails, bce returns to "early" command level with
only the initial hardware units accessible.
At the "boot" command level, the operator may again change
the config deck. Any units added, for example, will not be
accessible at this time, since the control tables do not describe
them. However, if the operator boots Multics service, Multics
will be able to access them all, since Multics boot will build
control tables for them all. If this boot fails, bce will return
to the "bce_crash" command level, with these new changes not
described in the control tables (but visible in the config deck).
Any changes made to the config deck will be reflected in the
control tables in only one of two ways. The first is to boot to
the next command level, or to Multics service. If the config
deck is correct, the devices become accessible. The other method
is to enter "reinitialize" which runs a new initialization pass
and returns to the "boot" command level. If this succeeds, the
devices become accessible. If it fails, bce returns to
"bce_crash" level, without the changes having been affected.
The process of coming to the bce "boot" command level
(whether via the "bce" command at the "early" command level or
the "reinitialize" command elsewhere) has certain significant
elements within it; in particular, the disk mpc's have firmware
loaded into them. Editing the config deck at the "boot" command
level in such a way as to change the state or number of the
mpc's, iom's, etc., may cause the booting of Multics service to
fail. Because of this, attempting to boot service after having
modified the config deck at the "boot" command level causes the
"boot" command to query the operator as to whether a
"reinitialization" should first be performed. A reinitialization
should be performed if the modifications made to the config deck
were not of a trivila nature. If in doubt, "reinitialize".
MOH-5.5-9
_B_C_E _F_I_L_E _S_Y_S_T_E_M _M_A_I_N_T_E_N_A_N_C_E
The bce file system generally maintains itself. The
contents of this file system, and its files, and any changes to
them, are maintained from bootload to bootload. However, it is
sometimes necessary to manually manipulate the file system (other
than by creating files).
Objects in the bce file system come into it within one of
three ways. First of all, the operator may enter a file with the
bce "qedx" command. Second, site administrators may use the
bootload_fs command to extract a copy of the bce file system
during Multics service, add new files, and replace the bce file
system with this new copy. Third, any files found within
collection 1.2 of the MST (Multics system tape) will be added to
the file system. (They will have the same names in the bce file
system as they did on the tape, overwriting any file with the
same name already present; however, any .ascii suffix will be
removed for compatibility with old releases.) Honeywell supplied
bce exec_com's come into the file system in this way. The site
is free to add any config deck sources or exec_com's that they
choose to the MST.
Since the bce file system is not impervious to damage, it is
recommended that sites do one of two things to protect the files
within it. One practice is to keep a copy of the bce file system
on line, so that an administrator may insert it if damage is
found. The other practice is to keep a copy of the needed
exec_com's and config deck sources on the MST, by locally
modifying >ldd>info>hardcore.header (and hardcore.search) and
generating a local copy of the MST.
If a problem is detected with the bce file system, the
operator should use the init_files bce request to reset the file
system. This request, however, will delete any files present
therein. These files can only be restored by rebooting, if the
files were present on the MST, or by rewriting the file system
from service.
_B_O_O_T_L_O_A_D _M_U_L_T_I_C_S _T_O_E_H_O_L_D
The bootload Multics toehold is a program that resides in
main memory. The toehold communicates very closely with the
control program in the manner described below.
When Multics is running, the toehold may be invoked by
manually forcing the processor to execute an XED 24000 (octal)
interrupt inhibited instruction. The CPU must be in TEST mode
when the XED instruction is executed. The toehold saves the
processor registers and the 512k of low memory. It then reads in
MOH-5.5-10
a saved copy of bootload Multics from the rpv and transfers
control to it. Bootload Multics then enters its command level
with a prompt of:
bce (crash) TIME:
The toehold is also invoked as a result of the "go" or
"continue" commands issued within bce. In this instance, the
toehold restores the memory image that it had previously saved
and restarts the program that was originally running.
The toehold contains a flagbox of bits that may be ON or OFF
and which can be read and set both by bce and Multics.
To enter bce manually, set the processor STEP switch to MEM,
enter 024000717200 (XED 24000 interrupt inhibited) in the
instruction switches (data switches), set the EXECUTE switch to
the EXECUTE SWITCHES position. Then, press the EXECUTE button,
set the STEP switch to OFF and press the STEP button. bce is
entered.
If your site has a DPS 8 system, the procedure for executing
switches will be different. Refer to Appendix M, "DPS 8
Operating Procedures", for details.
_E_M_E_R_G_E_N_C_Y _S_H_U_T_D_O_W_N _F_R_O_M _S_W_I_T_C_H_E_S
The emergency shutdown facility of Multics, normally
performed from bce, can be invoked directly from the processor
switches. This is normally done only if the system should be in
a hung state and it is not possible to return to, or operate bce.
(This may occur, for example, if no consoles are operative.) To
invoke this facility, execute a XED 24002 interrupt inhibited
instruction. This is done in a manner similar to that for
invoking bce manually from the switches (described in the
previous section), but with a data switch value of 024002717200.
_T_H_E _E_A_R_L_Y _D_U_M_P _F_A_C_I_L_I_T_Y
The early dump facility is a primitive facility within bce
that is capable of saving an image of memory to tape upon a
system failure early within initialization. It is invoked
automatically whenever a hardware or software error is detected
prior to the establishment of the bootload Multics toehold. It
can also be entered manually, during other bce initialization
phases, by executing the early dump entry to the toehold. This
is done in a manner similar to forcing a manual return to bce,
except that the value entered into the data switches is
024004717200 (XED 24004 interrupt inhibited).
MOH-5.5-11
Once entered, the early dump facility may print a flagbox
message and then prompt with:
Enter tape drive number for memory dump:
to which the operator should provide the drive number on the
bootload tape controller on which a tape is mounted for writing.
Memory will be dumped onto this tape at a density of 1600. After
performing the dump, bce will disable itself. If bce was booted
from BOS, BOS may be entered manually at this time.
The tape written by this facility can be read by the
read_early_dump_tape (redt) command, described in the System
Maintainer's Guide.
_B_C_E _C_O_M_M_A_N_D _L_A_N_G_U_A_G_E
The command language used within bce is the normal Multics
command language (actually the ssu_ request language), not to be
confused with the command language used at the Initializer's ring
1 and ring 4 command levels. (Refer to MPM AG91 - Reference for
a description of Multics command/subsystem language.) Full
support for active functions, iteration sets, etc. is provided.
Commands to bce are obtained from the bootload console,
using standard typing conventions. It is also possible for bce
commands to be placed into exec_com's. exec_com's are ascii
files containing commands and possible input to commands. They
are edited within bce via the "qedx" command and placed into
operation with the "exec_com" command.
Also, a command may be placed in the flagbox within bce or
Multics for bce to execute whenever Multics crashes or shuts
down.
Whenever at bce command level, bce responds with:
bce (boot) TIME:
(or "early" or "bce_crash" or "crash", depending on the
circumstances). Some commands have sub-requests to them, such as
qedx and probe. The conventions for request lines entered for
such commands varies from command to command.
_A_B_O_R_T_I_N_G _B_C_E _C_O_M_M_A_N_D_S
Whenever the REQUEST button is pushed on the console (or the
RETURN key on the CSU6601) when such a request was not solicited
by bce, the bce abort routine is entered. This routine allows
MOH-5.5-12
bce operations to be aborted to various extents. When called,
the abort function prompts (on the console) with:
Abort?
to which various answers may be given. If the REQEUST button was
hit accidentally, the operator may enter "no" or "n" to return to
the interrupted operation. Answering "yes" or "y" aborts the
immediate operation. If this operation was a sub-request, only
this sub-request is aborted. Otherwise, the command in question
is aborted, returning either to the exec_com which called it, if
one was present, or to bce command level. Answering "r", "req"
or "request" is equivalent to "yes". An answer of "command",
"com" or "c" aborts the current command, regardless of whether a
sub-request was in execution or not. Finally, an answer of "all"
or "a" aborts anything in execution, returning to bce command
level.
_B_C_E _C_O_M_M_A_N_D_S
The current set of bce commands and active functions is
listed below. Various commands are valid only at certain command
levels; the valid levels for each command is provided in the
description of the command.
bce also includes most of the standard active functions; in
particular, the standard arithmetic, character, boolean and
comparison active functions are included. The current list
includes:
after, af and
before, be bool
ceil collate
collate9 copy_characters, cpch
date_time_after, dtaf date_time_before, dtbe
date_time_equal, dteq date_time_valid, dtv
decat divide
equal floor
greater high
high9 index
length, ln less
low lower_case, lowercase
ltrim max
min minus
mod nequal
ngreater nless
not or
plus query
quotient response
reverse reverse_after, rvaf
reverse_before, rvbe reverse_decat, rvdecat
MOH-5.5-13
reverse_index, rvindex reverse_search, rvsrh
reverse_verify, rvverify rtrim
search, srh substr
time_after, taf time_before, tbe
time_equal, teq times
trunc upper_case, uppercase
verify
_S_u_m_m_a_r_y _o_f _b_c_e _c_o_m_m_a_n_d_s
alert
Write an alert message on the console.
bce
Complete the booting of bce.
bce_state, bces
Returns the current state (command level) of bce.
boot
Boot Multics.
bos
Return to bos, if present.
config_edit, config
Enter the config deck editor.
continue, go
Restart the interrupted Multics image.
delete, dl
Delete a bootload file.
die
Abort bce.
dump
Create a dump of Multics in the dump partition.
emergency_shutdown, esd
Perform an emergency shutdown of Multics.
exec_com, ec
Execute a file of bootload Multics commands.
fwload, fw
Load firmware into an mpc.
get_flagbox, gfb
Get the value of a flagbox variable.
MOH-5.5-14
init_files
Initialize the bootload file system.
list, ls
List bootload files.
list_requests, lr
List bootload requests.
print, pr
Print a bootload file.
probe, pb
Examine/modify the Multics image.
qedx, qx
Edit bootload text file.
reinitialize
Re-perform Multics initialization.
rename, rn
Rename a bootload file.
set_flagbox, sfb
Set the value of a flagbox variable.
severity
Returns the severity of a bce request.
shutdown_state, sds
Returns the shutdown state of the storage system.
MOH-5.5-15
Name: alert
The bce alert command writes a message on the operator
console with an audible alarm. This is useful in auto exec_coms
to inform the operator that the system has crashed. This command
is valid at all bce command levels.
Usage
alert The system has crashed!!!
MOH-5.5-16
Name: bce
The bce bce command causes bce to complete its
initialization. It is valid only at the "early" command level.
Usage
bce
MOH-5.5-17
Name: bce_state, bces
The bce bce_state returns the name of the current bce state
(command level). Possible results are "early", "boot",
"bce_crash" and "crash".
Usage
bce_state
MOH-5.5-18
Name: boot
The bce boot command causes the next phase of initialization
to proceed. It is used at the "boot" or "bce_crash" command
levels to boot Multics service. It is not valid at the "crash"
or "early" command levels. The command can also supply certain
parameters that will apply to the bootload of Multics.
Usage
boot {command} {keywords} {-cold} {-time}
where:
1. command is one of the following ring 1 command abbreviations:
star startup
mult multics
salv salvage_dirs
stan standard
2. keywords can be one or more of the following:
nodt
recreates the disk table; renames and ignores the
existing one.
nolv
recreates the logical volume registration directory
(>lv); renames and ignores the existing one.
rlvs
performs a volume salvage of the rpv (root physical
volume), a directory salvage of all directories used in
initialization and a volume salvage of all other member
volumes of the rlv (root logical volume).
rpvs
performs a volume salvage of the rpv and a directory
salvage of all directories used in initialization.
3. -cold
specifies that the root dir is to be re-created, thus
destroying the old file system hierarchy. This option
should only be used when a cold boot of bce was also
performed. The operator will be queried as to whether
bce should continue.
4. -time
specifies that the time should be set before performing
the next phase of initialization.
MOH-5.5-19
Notes
The boot command will query the operator if the "-cold"
argument is used. Also, if the config deck was modified at this
command level, the operator will be queried as to whether a boot
should be performed without a "reinitialize" having been
performed. Either of these queries can be avoided by using the
"-force" ("-fc") control argument.
MOH-5.5-20
Name: bos
The bce bos command causes bce to return to BOS, if bce was
booted from BOS. BOS may return to bce with the use of the BOS
"CONTIN" or "GO" commands. This command is valid at all bce
command levels.
Usage
bos
MOH-5.5-21
Name: config_edit, config
The bce config command enters the config deck editor. This
editor is identical in function to the qedx text editor, except
that buffer 0 contains an ascii source form of the config deck.
This command is not valid at the "crash" command level.
Usage
config_edit {file_name}
Notes
If a file_name is supplied on the command line, the
specified file is read into the config deck without entering the
config deck editor.
If not supplied a file_name, upon entry, the current config
deck (that found in the "conf" partition on the rpv) is read into
buffer 0. It is converted to a labeled ascii form which is an
expanded form of that used in the configuration card description
section. Arbitrary text editing operations may be performed upon
this buffer, as well as any other. Performing a "w" (write)
request upon buffer 0 writes the edited buffer back into the
config deck.
A read or write with a file name is allowed within any
buffer. Reads or writes without a file name in any buffer but 0
follow the usual qedx conventions. A read or write without a
file name in buffer 0 refers to the active config deck. A
conversion from/to binary will be performed by such a read/write.
In the labeled form, each field, except for the card name,
may be optionally preceded by a label. Labeled fields may appear
in any order. The interpretation of a card in labeled form is
that all labeled fields are placed into their proper places; any
unlabeled fields then fill in the missing spaces. Thus,
iom -state on -port 1 a nsa
becomes
iom a 1 nsa on
in its standard form.
The various labeled forms appear in Section 6 (Configuration
Description). If a card is to be entered whose format has been
locally changed or of a otherwise unknown format or type, a "."
may be placed in front of the card name to avoid errors during
MOH-5.5-22
parsing of the card. Such a card may not have any labeled
fields.
The operator should keep in mind the discussion in "Config
Deck and Device Accessibility", above for details on the
implications of this command. Note that a modification performed
to the config deck at the "boot" command level should be followed
by the "reinitialize" command. The operator will be queried if a
boot is attempted without a "reinitialize" having been performed.
MOH-5.5-23
Name: continue, go
When Multics is interrupted as the result of a manual return
to bce or as the result of encountering a bce probe breakpoint,
the machine image is saved. The bce continue command restores
the machine image and continues running the interrupted activity
(usually Multics). This command is valid at the "bce_crash" and
"crash" command levels.
Usage
continue
MOH-5.5-24
Name: delete, dl
The bce delete command deletes files within the bce file
system (not the Multics storage system). The star convention is
allowed. This command is valid at all bce command levels.
Usage
delete star_name {... star_names}
MOH-5.5-25
Name: die
The bce die command aborts all bce activities. It wipes out
the bce toehold, preventing any returns to bce, manual or
otherwise. It should be used only when it is desired to
absolutely kill off any remnants of bce. This command is valid
at all bce command levels.
Usage
die
Note
The die command queries the operator as to whether bce
should really be killed off. This query may be avoided by using
the "-force" ("-fc") control argument.
MOH-5.5-26
Name: dump
The bce dump command produces a diagnostic dump of system
memory and tables after a hardware or software failure, for later
analysis. The dump is produced by copying binary images of
segments and directories into the dump partition of the disk
described by the part dump config card. Arguments to the dump
command specify which processes are to be examined and which
segments from these processes are to be dumped. (See "Notes" for
a general purpose command line.) This command is valid at all
bce command levels.
Usage
dump {macro_keyword}
{-process_group segment_option {...segment_options}}
{-force | -fc} {-dump #} {-crash} {-bce}
where:
1. macro_keyword
specifies one of the following default group of processes
and segments to dump.
-brief, -bf is equivalent to -run hc pp dir
-short is equivalent to -run hc pp dir -elig hc
-long, -lg is equivalent to -all wrt
2. process_group
specifies a group of processes to be considered for dumping.
The segments that get dumped for processes in this group are
specified by segment options that follow the process group
keyword. Allowed groups are:
-running, -run
processes running on a processor (apte.state = running
or stopped)
-initializer, -inzr
the initializer process (first apte entry)
-eligible, -elig
all running and eligible processes (processes being
considered for running)
-all
all processes
3. segment option
specifies a class of segments to be dumped for the group of
processes specified by the process group keyword. Segment
classes are:
MOH-5.5-27
directories, dir
directory segments (aste.dirsw = "1"b)
hardcore, hc
the pds, kst, dseg and ring 0 stack for the
process(es). If a process is running, this also dumps
the prds for the processor in question.
modifying_dirs, moddir
directory segments (aste.dirsw = "1"b) which were being
modified at the time of the crash (dir.modify ^= "0"b)
per_process, pp
the segments contained within the process directory of
the process(es) (aste.per_process = "1"b)
stacks, stk
all stack segments in the process(es) not already
dumped by the hc or pp keywords.
writeable, wrt
all segments to which the process(es) have write
access. This keyword produces a very large dump.
Writable ring zero segments (system data bases) other
than directories are dumped regardless of what keywords are
specified.
Prefixing a segment option with a circumflex (^)
reverts an earlier occurence of the given segment option.
Thus, one can turn use a macro_keyword and turn off a
specific segment option within it.
4. crash or bce
specifies what bce should dump. The default is to dump the
saved Multics image. A dump of bce itself (the dumper) can
be made by specifying -bce.
Notes
For general purpose dump analysis, the command line:
dump -run hc pp dir -elig hc stk -inzr hc stk
should give the user all of the useful processes and segments (to
produce a smaller dump, remove the "dir" keyword). For
simplicity and to remove the possibility of operator error, this
command line should be placed into a bce exec_com, either by
itself or in a site supplied crash exec_com.
The dump command examines the active process table entries
(apte) within the specified image. For each entry, the criterion
MOH-5.5-28
specified through the keywords is used to decide if any segments
from this process are to be dumped. If any segments are to be
dumped, the segment options are applied to each segment active
within that process to decide whether or not they should be
dumped. As each process is dumped, dump will produce an output
line showing the apte number and the dbr value for the process.
After scanning all apte entries, if the process in control when
Multics crashed was not one of the processes dumped, it is dumped
with a status line showing an apte number of zero. This process
is dumped with the running and initializer segment options.
Within the dump partition is kept a counter and a valid
flag. When a dump is placed into the partition, the valid flag
is set. It is reset when the dump is copied out during Multics
service (by the copy_dump exec command). If the dump in the
partition has not been copied, dump will query the operator if it
should be overwritten. This query can be avoided by specifying
the "-force" ("-fc") control argument to the dump command.
Dumps are assigned dump numbers sequentially by default.
The dump number may be changed to a desired value with the -dump
control argument.
The dump command provides a severity indicator, indicating
the successful of its operation. This indicator may be obtained
with the severity command/active function. The interpretation of
the severity status is:
0 - the dump was successfully generated.
1 - dump was aborted because the partition contained an old
dump.
2 - dump was entered but never completed.
3 - dump was never called.
MOH-5.5-29
Name: emergency_shutdown, esd
The bce esd command starts an emergency shutdown of Multics.
It is only valid at the "crash" command level. It should be used
whenever the system crashes to prevent storage system damage.
Performing an emergency shutdown destroys the saved crash image
and should therefore only be done after a dump is taken.
Usage
esd
MOH-5.5-30
Name: exec_com, ec
The bce exec_com command invokes a bce exec_com. An
exec_com is an ascii file consisting of a series of commands to
invoke. bce uses exec_com version 1, described in AG92 (Commands
and Active Functions). This command is valid at all bce command
levels. This may also be used as an active function, as
described in AG92.
Usage
exec_com ec_name {ec_arguments}
Notes
Executing a "boot", "bce", "continue", "emergency_shutdown",
"reinitialize" or "die" command within an exec_com will cause the
exec_com to finish execution, in as much as that control will be
taken away from bce. When control does return to bce, this
exec_com will not continue from this point of interruption.
MOH-5.5-31
Name: fwload, fw
The bce fwload command loads firmware into the specified
mpcs. It scans the config deck to determine the location of the
mpcs and the type of peripherals involved to determine the
firmware and overlays needed. This command is not valid at the
bce "early" command level.
Usage
fwload mpc_name {... mpc_names}
Note:
This command cannot load firmware into active disk mpcs.
This can only be done in response to the load_disk_mpc query
during an initialization pass. To force loading firmware into a
disk mpc, stop the mpc and then enter "reinitialize".
MOH-5.5-32
Name: get_flagbox, gfb
The bce get_flagbox command is used to determine the values
of various variables maintained in the bce flagbox. These
variables are also accessible from Multics service and therefore
allow a small method of communication between bce and Multics
service. This command is valid at all bce command levels. It
also works as an active function.
Usage
gfb flagbox_variable
where flagbox_variable is one of the following:
N
where N is from 1 to 36. The returned value is the Nth
flagbox flag. These flags have true or false values.
Some of them are named and can be refered to by their
names, as listed below.
auto_reboot
(also flag 1) Used by the auto bce exec_com. Refer to
Appendix I (Continuous Operation Exec_coms) for more
details.
booting
(also flag 2) Used by the auto bce exec_com.
rebooted
(also flag 4) Used by the auto bce exec_com.
unattended
(also flag 5) Used by the auto bce exec_com.
bce_command
a command that is invoked by bce whenever it reaches a
command level. The result is a character string,
quoted. This command may be set so that bce can be set
to automatically boot Multics upon a crash, etc. Refer
to Appendix I for more details.
ssenb
a flag set by Multics service indicated whether or not
the storage system was enabled at the time of a crash.
A value of true indicates that an emergency shutdown
needs to be performed (or did not succeed).
call_bce
indicates that bce was called through a program calling
call_bce. This may be the result of the operator
having entering the bce command.
MOH-5.5-33
shut
indicates that Multics successfully shutdown. If
neither shut nor call_bce is set, Multics either
encountered a breakpoint, crashed or was manually
brought to bce.
manual_crash
indicates that bce was invoked manually, either by the
operator manually forcing a return to bce (XED 24000)
or by hitting the EXECUTE FAULT button.
MOH-5.5-34
Name: init_files
The bce init_files command wipes out all files in the bce
file system in a way independent of the (possibly damaged) state
of the bce file system. It is to be used only if a problem is
encountered with the bce file system. Refer to the section on
bce file system maintenance for more details. This command is
valid at all bce command levels.
Usage
init_files
Note
init_files will query the operator as to whether the bce
file system is to be cleared. This query may be avoided by using
the "-force" ("-fc") control argument.
MOH-5.5-35
Name: list, ls
The bce list command lists the names of bce files matching a
set of star names. It is valid at all bce command levels. It
can also be used as an active function to return the set of
names. When used as a command, providing no star names will list
the names of all bce files.
Usage
list {star_names}
MOH-5.5-36
Name: list_requests, lr
The bce list_requests request lists all requests valid at
the current command level.
Usage
list_requests
MOH-5.5-37
Name: print, pr
The bce print command prints the contents of a file in the
bce file system. This command is valid at all bce command
levels.
Usage
pr file_name
MOH-5.5-38
Name: probe, pb
The bce probe command is used to examine, patch and
generally debug Multics hardcore, bce itself as well as providing
a general memory and disk patch/dump facility. Its requests have
a fair resemblance to those of Multics probe. It can be used at
all bce command levels.
Usage
pb {control_arguments}
where valid control arguments are:
-bce to examine bce itself
-crash to examine the saved crash image
-break to examine the active breakpoint
The default, when invoked at the "boot" command level is to
examine bce, when invoked automatically upon encountering a
breakpoint is to examine the breakpoint and otherwise is to
examine the crash image.
Notes
bce probe reads request lines from the bootload console.
Multiple requests may appear on one line separated by
semi-colons. The syntax of these requests varies from request to
request. The recognized requests are listed below. Various
other aspects of bce probe are described in the following
sections.
ADDRESSES
Several requests in bce probe take an address describing
what should be displayed, modified, etc. These addresses can
take many forms, depending on what is desired. Valid address
forms are:
N
specifies absolute memory location N. N may describe
any location in all of memory. N is specified in
octal.
M|N
specifies the virtual location N in segment M. The
interpretation of this virtual address depends on the
MOH-5.5-39
address space being examined; refer to the "dbr" and
"proc" requests. Both N and M are octal values.
NAME|N
specifies the virtual location N in the hardcore
segment with the specified NAME. This interpretation
is also subject to the address space being examined. N
is specified in octal.
.{+|-N}
specifies the last location referenced (of any address
type) optionally offset by the value N. N is an octal
value.
reg(NAME)
specifies the named register in the crash image. This
address is not valid when examining the live bce.
Valid registers are:
prN (N = 0 to 7)
xN (N = 0 to 7)
a, q, e
t, ralr
fault, ext_fault, mode, cache
dbr, bar
disk(DRIVE_NAME,RECORD_NUM,OFFSET)
refers to a specific page of a disk drive. The drive
name is in the standard form, dska_04, for example.
Both RECORD_NUM and OFFSET (within the page) are octal
values.
PROBE REQUESTS
before, b {ADDRESS}
sets a breakpoint before the specified address. If no
address is specified, "." is assumed. Refer to
Appendix O for more details about hardcore breakpoints.
continue, c
continues the saved image. It is the same as exiting
probe and entering "continue".
dbr VALUE1 {VALUE2}
sets the dbr (descriptor base register) value used in
the appending simulation used to access virtual
addresses in the Multics image. If VALUE2 is omitted,
the second word of the dbr value is obtained from the
dbr in effect when Multics crashed. Both VALUE1 and
VALUE2 are octal values.
MOH-5.5-40
display, ds ADDRESS {MODE {LENGTH}}
displays a set of locations in a specified mode. If
LENGTH is omitted, a value of 1 is assumed. For
virtual addresses, a LENGTH of "*" may be specified to
display to the end of the segment. If MODE is omitted,
octal is assumed. Valid modes are:
a - ascii characters d - decimal words i - instruction
format o - octal words (default) p - symbolic pointer
(double words)
The locations are displayed four to a line in the
desired format. The value of "." after this request
finishes is the first location displayed.
let, l ADDRESS = VALUE {... VALUE}
modifies a series of locations starting at the address
specified. Each value is converted to a number of
words and catenated together to form the new value.
Valid values are:
"STRING"
a quoted string of characters. To place a quote
character into the string, it must be doubled.
N
a decimal number
No
an octal number
Nb
a binary number
M|N
a pointer to segment M offset N (double word)
NAME|N
a pointer to the named hardcore segment offset N
(double word)
list_requests, lr
lists the valid bce probe requests.
mc ADDRESS {-long | -lg}
displays, in interpreted form, the scu data found
within the machine conditions at the specified address.
Specifying "-long" also dumps the machine registers
from the machine conditions.
name SEGNO
displays the name of the hardcore segment with segment
number SEGNO.
MOH-5.5-41
proc N
changes the address space used by the appending
simulation for displaying virtual addresses to the Nth
process in the active process table. A value of 1
specifies the Initializer's process.
quit, q
exits probe.
reset, r {ADDRESS}
resets the breakpoint at the specified address. If
address is not specified, the currently active
breakpoint (if so existing) is reset. Refer to
Appendix N for more details of hardcore breakpoints.
segno NAME
displays the segment number of the named hardcore
segment.
stack, sk ADDRESS
displays a stack trace starting at the given address.
If the word offset of the address is 0, the address is
assumed to refer to a stack header. Otherwise it is
assumed to refer to a stack frame. For each frame, the
stack frame offset, entry pointer, return pointer and
argument pointer is displayed.
status, st {SEGNO|NAME}
displays a list of breakpoints set. If no argument is
supplied, all segments with breakpoints set are
displayed. If a SEGNO or NAME (of a hardcore segment)
is provided, then all breakpoints within that segment
are displayed.
MOH-5.5-42
Name: qedx, qx
The bce qedx command invokes the qedx text editor to edit a
bce file system file. All requests of the standard Multics qedx
editor are supported except for the "e" request. This command is
valid at all bce command levels.
Usage: qedx {-control_args} {macro_file} {macro_args}
Notes
Refer to the description of the qedx command in AG92
(Commands and Active Functions).
MOH-5.5-43
Name: reinitialize
The bce reinitialize command causes bce to perform a new
initialization pass, thereby reflecting any changes to the config
deck made since the last such pass. This command returns the
operator to "boot" command level. It is valid at the "boot",
"bce_crash" and "crash" command levels. When used at the "crash"
command level, the operator is asked whether to continue, thereby
destroying the saved Multics image. This query may be avoided by
using the "-force" ("-fc") control argument. The "-time"
argument allows the setting of the clock before reinitializing.
Usage
reinitialize {-time}
MOH-5.5-44
Name: rename, rn
The bce rename command renames files in the bce file system.
The star and equal conventions are used. This command is valid
at all bce command levels.
Usage
rename STAR_NAME EQUAL_NAME {... STAR_NAME EQUAL_NAME}
MOH-5.5-45
Name: set_flagbox, sfb
The bce set_flagbox command changes the values of various
flagbox variables. When used as an active function, it also
returns the previous value of the variable. It is valid at all
bce command levels.
Usage
set_flagbox VARIABLE VALUE
where
VARIABLE
is a valid flagbox variable, as listed above under
get_flagbox.
VALUE
is either a character string (for the bce_command
variable) or the string "true" or "false" for other
flagbox variables.
MOH-5.5-46
Name: severity
The bce severity command returns the severity, or extent of
completion, of a preceding bce command. This command is valid at
all bce command levels. Currently, the dump command provides
such a severity status. Future bce commands may also. This
command may also be used as an active function.
Usage
severity PROG_NAME
MOH-5.5-47
Name: shutdown_state, sds
The bce shutdown_state command returns the state of
completion fo the shutdown of Multics service. It does this by
examining the shutdown_state flag in the label of the rpv. This
request is valid at all bce command levels. It may also be
invoked as an active function.
Usage
shutdown_state
Notes
The interpretation of the shutdown states follows.
0 - Normal Multics shutdown (no esd)
1 - esd part 1 started (memory flush of modified pages
of segments)
2 - esd part 1 completed
3 - shutdown or esd completed with lock errors
4 - shutdown or esd completed with no errors
other - shutdown completed with errors, or not completed for
one or more disk errors
MOH-5.5-48
SECTION MOH-6
MULTICS CONFIGURATION DESCRIPTION
Besides changing config cards to appear in lower case, most
config cards now have a labeled form. Add to each applicable
config card description a new entry labeled:
Labeled format
with the appearance listed below.
Name: chnl
Labeled format
chnl -subsys device_name -iom iom1 -chn chn1 -nchan nchan1
{... -iom iom4 -chn chn4 -nchan nchan4}
Name: clok
Labeled format
clok -delta delta -zone zone -boot_delta boot_delta
Name: cpu
Labeled format
cpu -tag tag -port port -state state -type type -model model
{-cache cache_size -exp_port exp_port}
Name: iom
Labeled format
iom -tag tag -port port -model model -state state
Name: mem
Labeled format
MOH-6-1
mem -port port -size size -state state
Name: mpc
Labeled format
mpc -ctlr ctlr_name -model ctlr_model -iom iom1 -chn chn1
-nchan nchan1 {... -iom iom4 -chn chn4 -nchan nchan4}
Name: part
Labeled format
part -part partname -subsys subsystem -drive drive
Name: prph
Labeled format
prph -device ccuN -iom iom# -chn channel# -model model#
prph -subsys dskN -iom iom# -chn channel# -nchan nchan
-model model1 -number d1 {-model model2 -number
d2...-model model5 -number d5}
prph -device fnpN -iom iom# -chn channel# -state state
prph -device opcN -iom iom# -chn channel# -model model# -ll
line_length -state state
prph -device prtN -iom iom# -chn channel# -model model#
-train train# -ll line_length
prph -device punN -iom iom# -chn channel# -model model#
prph -device rdrN -iom iom# -chn channel# -model model#
prph -subsys tapN -iom iom# -chn channel# -nchan nchan
-model model1 -number d1 {-model model2 -number
d2...-model model5 -number d5}
Name: root
Labeled format
root -subsys subsystem1 -drive drive1 {... -subsys
subsystemN -drive driveN}
Name: schd
Labeled format
MOH-6-2
schd -wsf wsf -tefirst tefirst -telast telast -timax timax
{-mine mine {-maxe maxe {-maxmaxe maxmaxe}}}
Name: sst
Labeled format
sst -4k sst1 -16k sst2 -64k sst3 -256k sst4
Name: tcd
Labeled format
tcd -apt apt -itt itt
Name: udsk
Labeled format
udsk -subsys subsystem -nchan nchan {-drive drive1 -number
count1 ... -drive drive6 -number count6}
MOH-6-3
SECTION MOH-7
INITIALIZER COMMANDS
_O_v_e_r_a_l_l _S_y_s_t_e_m _C_o_n_t_r_o_l
change the BOS command to bce
_C_O_M_M_A_N_D _D_E_S_C_R_I_P_T_I_O_N_S
delete the BOS command and replace it with:
Name: bce
The bce command causes bce to be entered. All Multics
operation is suspended. When the system is in trouble, it is
sometimes necessary to enter bce to use the dump or probe
commands. This command may be issued in ring 1 or ring 4.
Usage
bce
causes the system to enter bce. Type:
! go
on the bootload console to cause Multics to be restarted.
(The notes pertaining to the BOS command also pertain to the bce
command.)
Name: cripple
replace references to BOS with bce.
MOH-7-1
Name: init_vol
add to the description of the default partitions the partitions
"file" of length 255 and "bce" of length 2200, both added to the
high end of the disk.
Name: message
The message command invokes the Multics qedx editor to edit
the file message_of_the_day, which most (but not all) users print
out automatically when they log in.
Usage
message
to edit the message. Editing requests may then be entered.
Usage of qedx is described in MPM Commands and Active Functions,
Order No. AG92.
MOH-7-2
SECTION MOH-8
SYSTEM STARTUP AND SHUTDOWN
Replace the entire section "Overview of System Startup) with the
following. Keep the sub-section entitled "Bringing up Multics
(Step by Step)" but change its title to "Bringing up Multics from
BOS (Step by Step)".
_O_V_E_R_V_I_E_W _O_F _S_Y_S_T_E_M _S_T_A_R_T_U_P
There are several steps to bringing up Multics service:
o Configure the system. The drive rpv must be mounted.
o Bootload BOS. This step is optional.
o Mount the RLV (if not already mounted) and all logical
volumes required at the site for starting.
o Boot bce from the current Multics system tape.
o Boot service Multics from bce.
o Start up the answering service and log in the daemons
to perform backup, input/output, and any other
specialized procedures (such as network interaction).
_B_o_o_t_l_o_a_d_i_n_g
A BOS bootload is the process of loading the programs that
make up the essential parts of BOS. BOS is used to bootload bce.
See "Loading BOS" in Section 5 for details on bootloading BOS.
It is not necessary to bootload BOS to bootload bce. However, if
BOS is not bootloaded, the functions of BOS may not be used in
conjunction with bce.
MOH-8-1
A bce/Multics bootload is the process of loading in the
programs that make up the Bootload Command Environment, who in
turn build up from themselves the Multics operating system. The
bootloading process loads the programs into memory, links them so
that they may refer to one another, and sets up any necessary
data bases. Whenever BOS is booted, bce must be re-booted. Any
number of service Multics boots may be made from a single bce
boot.
The programs on a Multics system tape are divide into
several collections. The first program on the tape, imbedded
within the tape label, is called bootload_tape_label. It reads
in the next set of programs, collection 0. Collection 0 is
responsible for reading in collection 0.5, used to boot firmware
into the bootload tape controller. Collection 0 then reads in
collection 1 and links the programs therein. This operation
allows programs written in PL/I to be used. Collection 1
contains the necessary programs to enable paging, as well as to
start up bce. Collection 1 uses collections 1.2, which contains
canned bce exec_coms and files and collection 1.5, which contains
some of the bce programs. bce also reads collections 2 and 3,
needed to bootload Multics service, onto disk.
When bce is finished, collection 2 is run to initialize and
set up the Multics storage system and the environment to do
reloads and other system startup activities. These programs (the
reloader) are found in collection 3.
_B_r_i_n_g_i_n_g _u_p _M_u_l_t_i_c_s _w_i_t_h _B_O_S _(_S_t_e_p _b_y _S_t_e_p_)
(was Bringing Up Multics (Step by Step))
o Bootload bce by typing:
BOOT N
(where N is the tape drive on which the Multics tape
[MST] is mounted).
o When bce responds with:
bce (boot) TIME:
bootload Multics service by typing:
boot star
or by invoking the continuous operation exec_com:
ec auto star
MOH-8-2
_B_r_i_n_g_i_n_g _u_p _M_u_l_t_i_c_s _w_i_t_h_o_u_t _B_O_S _(_S_t_e_p _b_y _S_t_e_p_)
To bring up Multics, proceed as follows:
o If not already in bce:
Configure the system hardware (see Section 3).
Mount the Multics system tape on a convenient tape
drive. Set the switches on the tape MPC to indicate
the tape drive, as described in "Bootloading bce from
the Operator's Console" in Section 5.5.
Boot bce from tape as described in Section 5.5.
o bce types the ready message:
bce (early) TIME:
This time may not be correct since the time zone is not
necessarily known at this time.
o Make sure the config deck is correct. Enter or modify
it if necessary.
o Enter
bce
to proceed to bce "boot" command level. This step will
check the validity of the clock. If the clock is not
valid, follow the steps described in Section 3
(Calendar Clock). This step also loads firmware into
all disk mpcs (except for the bootload disk mpc).
o Load firmware into all controllers, except for disk
mpcs and the bootload tape controllers (who have
already been loaded in the bce bootload sequence).
o Mount all required disk volumes.
o Press the INITIALIZE AND CLEAR pushbutton on the
processor configuration panel for all CPUs except the
one on which you are running.
o Bootload Multics service by typing:
boot star
or by invoking the continuous operation exec_com:
ec auto star
MOH-8-3
o After Multics types an introductory message and
requests a command, press the REQUEST button at the
operator console.
o Operate the initializer process as outlined in the
following paragraphs.
_A_d_m_i_n_i_s_t_r_a_t_i_v_e _R_i_n_g _C_o_m_m_a_n_d_s
...If a ring 1 command was specified in the boot command,
this command is executed automatically. For example, typing:
boot star
executes the star (startup) command in ring 1....
_S_A_M_P_L_E _S_T_A_R_T_U_P _S_E_Q_U_E_N_C_E
! ec auto star
_U_N_A_T_T_E_N_D_E_D _A_N_D _A_U_T_O_M_A_T_I_C _M_O_D_E_S
Change all references to the BOOT command to refer to the boot
command and all references to the AUTO runcom to refer to the
auto exec_com.
MOH-8-4
SECTION MOH-10
RECOVERY FROM SYSTEM FAILURE
_S_Y_M_P_T_O_M_S _O_F _S_Y_S_T_E_M _F_A_I_L_U_R_E
o The system returns to bce without operator intervention.
_R_e_t_u_r_n_i_n_g _t_o _b_c_e
If the system loops or crashes and does not return to bce,
the operator presses the EXECUTE button to force the system to
return to bce. This can be done in one of two ways.
1. Usually bce is entered by causing an execute fault.
For this to occur, the EXECUTE SWITCHES switch must be
down when the EXECUTE button is pushed. (This switch
may have been left in the up position.) DO NOT put the
processor in STEP when using the execute fault. An
execute fault must be used to force a return to bce
when two or more cpus are in use.
2. bce can also be entered by executing the instruction
pair located at octal location 24000 in memory. In
this case, the 24000 is set in switches 0-17 and an
interrupt-inhibited execute double (XED) instruction is
set in switches 18-35 (the octal value of the switches
should be 024000717200). If the EXECUTE SWITCHES
switch is in the up position when the EXECUTE button is
pressed, the XED is executed; the processor should be
in STEP when the button is pushed. bce should be
entered with an XED only in cases noted below, or as a
last resort. This method does not stop any additional
CPUs. If, as a last resort, this method is used when
more than one CPU is running, all CPUs other than the
bootload CPU should be put into STEP, and the forced
execution performed on the bootload CPU.
MOH-10-1
If your site has a DPS 8 system, the procedures for
executing switches and placing a CPU in step will be different.
Refer to Appendix M, "DPS 8 Operating Procedures", for details.
(The procedure for executing fault will be the same.)
_I_O_M _A_l_a_r_m
change all references to BOS to bce.
_R_e_c_o_v_e_r_y _a_f_t_e_r _a _S_y_s_t_e_m _F_a_i_l_u_r_e
change all references to BOS to bce.
Change as follows:
...There are 36 switches set up in the bce toehold for
intercommunication between Multics and bce. These switches are
set either by the bce set_flagbox command or the Multics
privileged command, set_flagbox (described in Appendix I). One
of these switches means "automatic reboot mode is on". When the
system is running in automatic mode and returns to bce, the
flagbox bce_command variable is set to a command that tests the
"crashed" indicators to discover whether the system failed or
shut down normally. If the test indicates a system failure,
automatic recovery procedures begin. These procedures are
described under "Recovery Procedures" below.
RECOVERY PROCEDURES
Automatic recovery procedures do the following:
o Take a dump (using the bce dump command). (See section
5.5 for description of this command.)
o Perform emergency shutdown (esd).
o Bring up the system again (boot). Required salvaging
is done automatically as the system is brought up....
RECOVERY FAILURE
change:
o System loop or failure to return to bce.
In this case, the operator enters bce via XED 24000.
MOH-10-2
bce senses this manual intervention and does not
perform the automatic operation specified in the
flagbox bce_command. The operator may invoke automatic
recovery by entering:
ec rtb
o The system_start_up.ec never finished.
In this case, the booting flag is still on. The
exec_coms take a dump and do an emergency shutdown, but
abort automatic mode.
o The auto_reboot flag is off.
Automatic mode may be turned off by the set_flagbox
command executed while Multics is running. As such,
the exec_coms print a message and exit after
recovering.
o Some disk volume cannot be accepted.
In this case, the initializer process has typed a
message and inhibited automatic startup. The system
waits at operator command level in ring 1 or ring 4,
depending on where the error is detected.
o dump failed.
In this case, the operator may choose to try again
(type "ec rtb") or to try an emergency shutdown. If
the dump failed because the previous copy_dump was not
successful (or not reached), and if the dump partition
is still full, the dump partition may be saved on tape
by BOS. This allows the new dump to be taken without
losing the old one. See "Saving the DUMP Partition"
later in this section.
o Explicit call to bce.
If bce is entered as a result of a call to
hphcs_$call_bce, the system assumes this is due to
operator intervention. The exec_coms print a message
and await console input. The operator is queried as to
whether automatic recovery should be performed.
o Lock error during shutdown.
If errors are encountered during an attempted shutdown,
the exec_coms print a message and await console input.
o Reboot loop.
If the system attempts to reboot itself repeatedly,
this may be a sign of some system problem that does not
prevent answering service startup but crashes the
system later. The standard system_start_up.ec does not
reboot the system twice without operator intervention,
because automatic mode gets turned off. If this plan
seems to be too conservative for certain installations,
MOH-10-3
the system_start_up.ec can be modified to take other
action.
_S_a_v_i_n_g _t_h_e _D_u_m_p _P_a_r_t_i_t_i_o_n
add a line specifying that bce must first return to BOS before
BOS can perform the dump. Also, BOS must perform a "go" to
restart bce.
_F_a_i_l_u_r_e_s _t_h_a_t _d_o _n_o_t _c_r_a_s_h
remove the reference to the BLAST command. Also change
references to BOS to bce.
Change subsequent references to BOS to bce within the chapter
except for references to the BOS save and restore commands. Make
all bce command names lowercase.
MOH-10-4
SECTION MOH-12
STORAGE SYSTEM MAINTENANCE OPERATIONS
_H_O_W _T_O _M_O_V_E _A _P_A_C_K
change:
...If any BOS runcoms or bce exec_coms name specific
drives...
...Load bce and Multics using BOOT.
MOH-12-1
SECTION MOH-A
SUMMARY OF OPERATOR COMMANDS
...Commands used within the bootload operating system (BOS)
or the bootload command environment (bce) are not included in
this list; for these see Section 5, "Bootload Operating System",
Section 5.5, "Bootload Command Environment", and the summaries in
Appendices C and N.
In the summary, change the bos command to be named bce and to
refer to bce.
MOH-A-1
SECTION MOH-B
SUMMARY OF INITIALIZER COMMANDS
Change the bos command to be named bce and change references to
BOS to bce.
MOH-B-1
SECTION MOH-C
SUMMARY OF BOS COMMANDS
Delete the ABS, BLAST, DUMP, ESD, FDUMP and PATCH commands.
MOH-C-1
SECTION MOH-H
OPERATOR'S STARTUP CHECKLIST OF SWITCH SETTINGS
_P_R_O_C_E_S_S_O_R _U_N_I_T _(_M_A_I_N_T_E_N_A_N_C_E _P_A_N_E_L_) _S_W_I_T_C_H_E_S
DATA SWITCHES Set to XED - Location 24000 (024000 717200)
MOH-H-1
SECTION MOH-I
CONTINUOUS OPERATION EXEC_COMS
This appendix describes the bce exec_coms supplied with the
system to implement automatic recovery after system crashes. The
operator usually types only the two command lines:
ec auto star
to initiate system bootload, with automatic restart if
a crash occurs.
ec go
to restart automatic operation after a manual return to
bce.
Descriptions of the get_flagbox and set_flagbox commands are
included at the end of this section.
_F_L_A_G _U_S_A_G_E
Several flags and indicators coordinate the bce and Multics
modes of operation. The bce and Multics get_flagbox and
set_flagbox commands are used to examine and set, respectively,
flags in the toehold. Four flags have preassigned meanings and
are known by keywords in these commands:
1. auto_reboot
TRUE if the system is to attempt to reboot itself after
it has crashed.
2. booting
TRUE during bootload. It is turned off at the end of
part 3 of system_start_up.ec, when bootload is over.
This flag prevents the system from looping to reboot if
it crashes before coming up.
3. rebooted
TRUE if the system has rebooted as a result of
automatic operation.
MOH-I-1
4. unattended
TRUE if the system is not attended by an operator.
In addition, the "call_bce" and "shut" flags may be examined to
determine the mode of bce entry. The "ssenb" flag may also be
tested to see if the storage system has been enabled.
_E_X_E_C__C_O_M_S
auto.ec starts automatic operation.
&command_line off
&- automatic reboot ec for bce
&- Keith Loepere, January 1984.
&-
&if [equal [bce_state] "early"] &then &goto cant_boot
&if [equal [bce_state] "crash"] &then &goto cant_boot
&print Begin auto boot.
set_flagbox bce_command ""
set_flagbox auto_reboot true
set_flagbox booting true
&input_line off
&attach
config_edit
gp/^cpu/
gp/^iom/
gp/^mem/
q
&detach
set_flagbox bce_command "exec_com rtb"
boot &rf1
&- wont return
&label cant_boot
&print The system cannot be booted from this bce state.
&quit
rtb.ec
determines what operations to perform upon a return to bce.
&command_line off
&- ec to handle returning to bce
&- Keith Loepere, January 1984.
&-
&if [not [get_flagbox call_bce]] &then &goto non_call_entry
&-
&print bce invoked via hphcs_$call_bce.
&-
&if [not [query "Should normal recovery procedures be used?"]] &then &goto abort_auto_mode
&-
&label non_call_entry
&-
MOH-I-2
&- look at the state of things
&-
&if [not [get_flagbox ssenb]] &then &goto ss_not_enabled
&-
&- storage system enabled; take a dump and esd
&-
exec_com dump
&-
&if [nequal [severity dump] 0] &then &goto dump_okay
&-
&print Dump failed.
&goto abort_auto_mode
&-
&label dump_okay
&-
emergency_shutdown
&- return from above is back at rtb
&-
&label ss_not_enabled
&-
&- Is everything okay?
&-
&if [nequal [shutdown_state] 4] &then &goto okay_shutdown
&-
&if [nequal [shutdown_state] 3] &then &print Shutdown with locks set.
&else &print Error during shutdown.
&goto abort_auto_mode
&-
&label okay_shutdown
&-
&- normal shutdown - see if we should reboot
&-
&if [not [get_flagbox unattended]] &then &goto abort_auto_mode
&if [not [get_flagbox auto_reboot]] &then &goto abort_auto_mode
&if [get_flagbox booting] &then &goto system_cant_boot
&-
set_flagbox rebooted true
&-
&- inform a.s. that we are doing an automatic reboot
&-
exec_com auto star
&quit
&-
&label system_cant_boot
&-
&print System crashed during boot.
&-
&label abort_auto_mode
&-
set_flagbox bce_command ""
set_flagbox auto_reboot false
set_flagbox rebooted false
&quit
MOH-I-3
dump.ec
performs a standard dump.
&command_line off
&- standard bce dump defaults
&- Keith Loepere, January 1984.
&-
dump -run hc pp moddir -elig hc stk -inzr hc stk &rf1
&quit
go.ec
restarts automatic operation after a manual return to bce.
&command_line off
&-
&- restart auto operation after manual bce entry
&- Keith Loepere, January 1984.
&-
set_flagbox auto_reboot true
set_flagbox rebooted false
set_flagbox booting false
set_flagbox bce_command "exec_com rtb"
go
&quit
MOH-I-4
SECTION MOH-M
DPS 8 OPERATING PROCEDURES
Change all references to the BOS whatever to the bootload
whatever.
EXECUTING SWITCHES
2. Having typed "VIP", you will receive the CPU CMD prompt.
When you see this, type "CO DATA 024000717200" followed by "EX2".
3. When the system has returned to bce, you'll see the bce ready
message displayed on the system bootload console.
PLACING A CPU IN STEP
5. Having typed "VIP", you will receive the CPU CMD prompt.
When you see this, type "CO DATA 024000717200" followed by "EX2".
6. When the system has returned to bce, you'll see the bce ready
message displayed on the system bootload console.
VIP MODE COMMANDS (UNT CMD PROMPT)
Delete the BOS command.
MOH-M-1
SECTION MOH-N
SUMMARY OF BCE COMMANDS
The Multics bootload command environment is described in
detail in Section 5.5. All of the commands available to bce are
summarized in this appendix for quick reference. This summary is
formatted so that it can be removed from the manual for use as
reference cards or for machine-room posting.
alert
Usage: alert message
writes a message on the operator console with an audible
alarm.
bce
Usage: bce
casues bce to complete its initialization.
bce_state, bces
Usage: bce_state
returns the name of the current bce state.
boot
Usage: boot {command} {keywords} {-cold} {-time}
causes bce to boot Multics service.
Valid commands: star, mult, stan, salv
Valid keywords: nodt, nolv, rlvs, rpvs
MOH-N-1
bos
Usage: bos
causes bce to return to BOS.
config_edit, config
Usage: config_edit {file_name}
enters the config deck editor.
continue, go
Usage: go
restores the machine image and continues running the
interrupted activity.
delete, dl
Usage: delete star_names
deletes files within the bce file system.
die
Usage: die {-force | -fc}
aborts all bce activities.
dump
Usage: dump {macro_keyword} {-process_group segment_option
{...segment_options}} {-force | -fc} {-dump #} {-crash}
{-bce}
produces a diagnostic dump of system memory and tables into
the dump partition.
Valid macro_keywords: -brief, -short, -long
Valid process_groups: -running, -initializer, -eligible,
-all
Valid segment options: directories, hardcore,
modifying_dirs, per_process, stacks, writeable
MOH-N-2
emergency_shutdown, esd
Usage: emergency_shutdown
starts an emergency shutdown of Multics.
exec_com, ec
Usage: exec_com ec_name {ec_arguments}
invokes a bce exec_com.
fwload, fw
Usage: fwload mpc_names
loads firmware into the specified mpcs.
get_flagbox, gfb
Usage: get_flagbox variable
determines the value of a variable maintained in the bce
flagbox.
init_files
Usage: init_files {-force | -fc}
wipes out all files in the bce file system.
list, ls
Usage: list {star_names}
lists the names of bce files matching a set of star names.
list_requests, lr
Usage: list_requests
lists all requests valid at the current command level.
print, pr
Usage: print file_name
MOH-N-3
prints the contents of a file in the bce file system.
probe, pb
Usage: probe {-break | -bce | -crash}
used to examine, patch and generally debug Multics hardcore
and bce itself.
Allowed requests:
before, b {ADDRESS}
sets a breakpoint before the specified address.
continue, c
continues the saved image.
dbr VALUE1 {VALUE2}
sets the dbr value used in the appending simulation.
display, ds ADDRESS {MODE {LENGTH}}
displays a set of locations in a specified mode.
let, l ADDRESS = VALUE {... VALUE}
modifies a series of locations.
list_requests, lr
lists the valid bce probe requests.
mc ADDRESS {-lg}
displays machine conditions.
name SEGNO
displays the name of the hardcore segment with segment
number SEGNO.
proc N
changes the address space used by the appending
simulation to the Nth process in the active process
table.
quit, q
exits probe.
MOH-N-4
reset, r {ADDRESS}
resets the breakpoint at the specified address.
segno NAME
displays the segment number of the named hardcore
segment.
stack, sk ADDRESS
displays a stack trace starting at the given address.
status, st {SEGNO|NAME}
displays a list of breakpoints set.
qedx, qx
Usage: qedx {-control_args} {macro_file} {macro_args}
invokes the qedx text editor to edit a bce file.
reinitialize
Usage: reinitialize {-force | -fc} {-time}
causes bce to perform a new initialization pass.
rename, rn
Usage: rename star_name equal_name {... star_name
equal_name}
renames files in the bce file system.
set_flagbox, sfb
Usage: set_flagbox variable value
changes the value of a flagbox variable.
severity
Usage: severity prog_name
returns the severity, or extent of completion, of a
preceding bce command.
MOH-N-5
shutdown_state, sds
Usage: shutdown_state
returns the state of completion of the shutdown of Multics
service.
MOH-N-6
SECTION MOH-O
HARDCORE BREAKPOINTS
The hardcore breakpoint facility is a collection of
facilities within Multics and bce that allow probe style
breakpoints to be set at most bce and hardcore instructions.
They may be used largely as they are within normal Multics probe
but with a few caveats.
_B_R_E_A_K_P_O_I_N_T _M_E_C_H_A_N_I_S_M
This section describes the mechanism by which hardcore
breakpoints is implemented. This is largely for academic
interest; however, a understanding of the mechanism will prevent
the user from setting a breakpoint in an incorrect path; in
particular, breakpoints may not be set in the breakpoint
handler's path.
When a hardcore breakpoint is set at an instruction, the
instruction at that location is relocated to the end of the
segment containing it. Its addressing is changed to reflect its
new location. The original location is replaced with a transfer
instruction to a breakpoint block at the end of the segment which
executes a "drl -1" instruction. This causes the breakpoint to
happen. If the breakpoint handler returns without changing the
breakpoint, the next instruction in the block will be executed.
This is the relocated original instruction. After this, a
transfer is made back to the correct place in the original
program. It should be noted that the instruction moved cannot be
the second or later words of an eis multi-word instruction.
Derail faults are handled in fim. A "drl -1" instruction is
special cased to be a breakpoint. fim makes a call to
pmut$bce_and_return to implement the call to bce. Any program in
this path (this part of fim, pmut, connect handling in stopping
other processors, etc.) cannot have a breakpoint placed therein.
Also, the special casing of a "drl -1" to be a breakpoint only
applies for derails in ring 0. Thus, breakpoints should not be
set in segments that will be executed in other rings.
MOH-O-1
When bce is invoked via the toehold, it notices that a
breakpoint was the cause of the return to bce and invokes bce
probe directly. Probe is free to perform a continue operation
which eventually returns to pmut, restarts other processors,
returns to fim who restarts the breakpointed operation.
Breakpoints may be set within bce also. However, they
should be set only at the "boot" command level. When set at the
"early" command level, a breakpoint will cause a return to the
"early" command level. Also, a breakpoint set at the "crash"
level is useless since, upon a breakpoint/crash of the "crash"
command level, the toehold purposely does not save the crash
image to avoid overwriting the Multics image already saved.
_B_C_E _P_R_O_B_E _B_R_E_A_K_P_O_I_N_T _O_P_E_R_A_T_I_O_N_S
This section describes bce probe support of breakpoints.
_B_r_e_a_k_p_o_i_n_t _r_e_q_u_e_s_t_s
before, b {address}
sets a breakpoint to be executed before executing the
instruction at the specified address. If no address is
specified, "." is assumed. The address must be a
virtual address. The breakpoint is added to the list
of breakpoints for the segment. Up to 120 breakpoints
may be set per hardcore segment; however, all wired
hardcore segments share the same breakpoint area so
only 120 breakpoints in total may be set in wired
segments.
continue, c
continue from a breakpoint. Multics is restarted.
reset, r {address}
resets a given breakpoint; that is to say, Multics will
no longer break when the instruction is encountered.
The breakpoint causing the return to bce can be reset
by not specifying an address.
status, st {name|segno}
either lists all segments with breakpoints set in them
(if no name or segno is specified) or lists all offsets
within a single segment at which a breakpoint is set.
MOH-O-2
_B_r_e_a_k_p_o_i_n_t _r_e_f_e_r_e_n_c_e_s
When a breakpoint causes a return to bce, bce does not
execute the bce_command in the flagbox. Instead, it enters probe
directly. Probe will assume a default of "-break". Probe may be
exited at this time. This does not effect a return to Multics
however, only a return to bce ("crash" or "bce_crash") command
level. Probe may also be entered with the control argument
"-break" to force examining the breakpoint conditions. The only
difference between "-break" and "-crash" for probe is the machine
conditions to use. "-crash" uses registers contained within the
toehold when the toehold was invoked. These registers are mostly
interesting when bce is manually entered. "-break" uses the
registers at the time of the breakpoint; these were saved by the
breakpoint handler. The registers will show the register
contents at the time of the breakpoint; however, the instruction
counter will show the relocated instruction, not its original
location.
MOH-O-3
-----------------------------------------------------------
Historical Background
This edition of the Multics software materials and documentation is provided and donated
to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc.
as a contribution to computer science knowledge.
This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology,
Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL
and BULL HN Information Systems Inc. to the development of this operating system.
Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970),
renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership
of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture
for managing computer hardware properly and for executing programs. Many subsequent operating systems
incorporated Multics principles.
Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc.,
as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. .
-----------------------------------------------------------
Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without
fee is hereby granted,provided that the below copyright notice and historical background appear in all copies
and that both the copyright notice and historical background and this permission notice appear in supporting
documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining
to distribution of the programs without specific prior written permission.
Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc.
Copyright 2006 by BULL HN Information Systems Inc.
Copyright 2006 by Bull SAS
All Rights Reserved