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 *cs* 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>csldd>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