SECTION 1 INTRODUCTION This document describes the MR11.0 package. Detailed instructions for installation of a system for the first time, upgrading to MR11.0 from an MR10.1 system, and upgrading to MR11.0 from an MR10.2 system constitute the major portion of this document. Future releases will require that sites be running the immediately previous release in order to migrate. Migration to the next release will require that sites be running MR11.0. No attempt is made to document features of MR11.0 other than those directly required for its installation. Software Releases prior to MR10.0 are no longer supported. All sites running pre-MR10.0 software are strongly encouraged to upgrade to MR11.0 as soon as possible. _S_I_T_E _S_U_P_P_O_R_T System Representatives who support Multics should apply for registration on the SiteSA project maintained in Phoenix on System M. The SiteSA project was created to allow sites to communicate with Multics System Support (MSS) personnel on matters of site support. MSS maintains and pays for usage on this project. Only System Representatives who support a Multics site are authorized to use the project. They are authorized to use it only for site support activities which require communication of information to MSS personnel. MSS would appreciate that the SiteSAs maintain the site's info segments in >udd>SiteSA>site_info (>udd>ssa>si). Information on maintaining these segments is in the info segment, >udd>ssa>si>site_info.info. Introduction 1-1 SIB11.0 In addition to normal telephone and Multics mail communications with MSS personnel, SiteSAs are encouraged to use the unusual_crash_log forum meeting to report any unusual problems encountered at their site. SiteSAs not familiar with forum can type "help forum" for usage information. Forum is a subsystem somewhat like the mail system in which an electronic meeting can be held. To invoke forum, type: forum >udd>ssa>sa_meeting>uclog Type ? to print a list of requests allowed by forum. Other forum meetings of interest to SiteSAs are: PATHNAME SHORT NAME --------------------------------------------- ---------- >udd>ssa>sa_meeting>install_instructions ii >udd>ssa>sa_meeting>hardware_problems hwp >udd>ssa>sa_meeting>critical_fixes fixes We would appreciate that sites as they complete installation of MR11.0 enter a transaction in the install_instructions (ii) forum meeting. This will allow other sites to see the amount of exposure the release is receiving and to communicate any problems encountered in the installation procedure. MSS also suggests, very strongly, that SiteSAs DO NOT attempt to reproduce site problems on System M which are known to crash the system at their site, cause processors to loop in ring 0, etc. Such problems should be reported via the Trouble Report system, and will be verified by MSS personnel using appropriate resources, so that System M service is not interrupted unnecessarily. Problems encountered while installing this release, or problems of a critical nature to a customer site (for a definition of critical, type: help tr.priorities) should be reported directly to MSS by mail or phone. European or Canadian sites should contact their local site support person for details on support from the Canadian, French or UK Technical Assistance Centers. Phoenix personnel include: NAME AREA USER ID PHONE George Gilcrease Multics TAC Gilcrease.TR 602/249-6864 Frank Martinson Mgr, MSS Martinson.sm 602/249-5563 Gary Dixon TRs, C&F, Site Support GDixon.sm 602/249-6772 Gary Johnson Sys. Integration Release Prep GJohnson.sm 602/249-6673 Note that all of the above numbers are available through HVN 249-XXXX (eg, 249-5563 for Martinson). Introduction 1-2 SIB11.0 SECTION 2 DESCRIPTION OF PACKAGE _L_I_B_R_A_R_Y _N_A_M_I_N_G _C_O_N_V_E_N_T_I_O_N_S The primary pathnames on most of the system directories are somewhat lengthy. For this document, abbreviated (added) names are used in lieu of the primary name. The following list gives the primary and abbreviated names used in this document. >daemon_dir_dir >system_library_1 >ddd >sl1 >documentation >system_library_obsolete >doc >obs >system_library_tandd >system_library_standard >firmware >sss >library_dir_dir >system_library_tools >ldd >tools >process_dir_dir >system_library_unbundled >pdd >unb >system_control_1 >user_dir_dir >sc1 >udd The system directories firmware and obs, are not included in the standard system search rules. Segments in these directories must either be accessed by absolute pathnames or by changing the system search rules via the set_system_search_rules command added to the system_start_up.ec. Package Description 2-1 SIB11.0 _C_O_N_T_E_N_T_S _O_F _M_R_1_1 _P_A_C_K_A_G_E MR11 includes this document, a set of magnetic tapes, hardcopy dump maps, and accompanying documentation. Sites not installing Multics for the first time will be able to proceed to the MR11 release from either MR10.1 or MR10.2. Sites upgrading to MR11 from MR10.2 refer to Section 4, sites installing Multics for the first time refer to Section 5, and sites upgrading to MR11 from MR10.1 refer to Section 6. The instructions in each section will provide a procedure to guide a site through the installation. Documentation for some of the new features in this release is contained in the directory >doc>MR11 which is part of this release. This is a total software release. It contains a complete set of all modules contained in the Multics standard system. Included in Appendix A is a description of the new Bootload Command Environment (BCE) in terms of its difference from the previous method of operation (i.e.BOS). Appendix B will list modules added or deleted since MR10.2. Appendix C contains detailed instructions for set up and use of Data Management. Appendix D contains an outline of the use of MTR under Multics. A set of master tapes was generated for this release and all dump maps reflect the contents of these master tapes. All tapes sent to the field are copies of the master tapes. Because of different lengths of magnetic tape reels, there may not be an exact correlation between a single tape and a dump map. These differences, if any, are minimal and occur only on those sets that are multi-reel (e.g., 11.0LISTINGS tapes). Site personnel may assure themselves of the contents of the tapes by visually matching the maps produced from the reload operations against the master dump maps supplied. Package Description 2-2 SIB11.0 _T_a_p_e__N_a_m_e_s _D_e_s_c_r_i_p_t_i_o_n 11.0EXEC Complete dump of Multics executable libraries >documentation, >obs, >sss, >tools, and >firmware. 11.0UNBUNDLED Complete dump of Multics unbundled libraries, or portion thereof, for those sites purchasing Priced Software Products. Includes all, or portions of >unbundled, >ldd>unbundled, >ldd>mcs and >system_library_3rd_party. 11.0LDD_STANDARD Complete dump of all standard library source, object, include files and info segs. 11.0LISTINGS ** Complete dump of all listings for modules compiled with the -list control argument. This includes the >ldd>listings>hardcore and >ldd>listings>bos subtrees. 11.0MULTICS Complete Multics System Tape (MST). 11.0BOS Complete Bootload Operating System (BOS) tape. 11.0MISC The compout segment for this document and other supporting documentation, if any, are contained on this tape in >doc>MR11.0. Last minute changes, if any, made to software modules after generation of the above tapes is also contained on this tape. This is the last tape to be loaded. ** The loading of this set of tapes is optional. If disk space is critical, it is suggested that these tapes be used only for retrieval of specific listing segments on an individual basis. Total storage required for the Hardcore and BOS is approximately 25,500 records. Package Description 2-3 SIB11.0 The accompanying hardcopy listings are: _L_i_s_t_i_n_g _D_e_s_c_r_i_p_t_i_o_n 11.0EXEC.DUMP.MAP Contents of the 11.0EXEC tape. 11.0UNBUNDLED.DUMP.MAP Contents of the 11.0UNBUNDLED tape (for those sites purchasing Priced Separate Software). 11.0LDD_STANDARD.DUMP.MAP Contents of the 11.0LDD_STANDARD tapes. 11.0LISTINGS.DUMP.MAP Contents of the 11.0LISTINGS tapes. 11.0MISC.DUMP.MAP Contents of the 11.0MISC tape. A detailed status of all MR11 modules contained on the Multics and BOS system tapes is included on the 11.0LISTINGS tapes in the following files: _T_a_p_e__F_i_l_e__N_a_m_e _D_e_s_c_r_i_b_e_s _system_book_ MR11 hardcore modules _bos_system_book_ MR11 BOS modules Package Description 2-4 SIB11.0 SECTION 3 FCO AND FIRMWARE STATUS _F_I_R_M_W_A_R_E The firmware identification for MR11.0 is "IFAD B.3". IFAD (Integrated Firmware and Diagnostics) tapes, are distributed to all sites having valid Field Engineering Hardware Maintenance contracts. The B.3 tape is distributed as FCO PHAFGA891. T&D (Test and Diagnostic) tapes, are distributed to all sites having valid Field Engineering Hardware Maintenance contracts. The T&D tape is distributed as FCO PHAFGA890. Prior to availability of the IFAD FCO, sites can use a pre-release version of the IFAD firmware and T&D modules which have been tested and exposed on System M in Phoenix. These pre-release modules are supplied as part of the MR11.0 release and can be found in >firmware as part of the EXEC tape. Once offical IFAD B.3 is available, it is recommended that the site use the load_tandd_library command to load the released IFAD tape into >system_library_tandd. The firmware modules should then be moved to >ldd>bos>firmware and new BOS and MST tapes should be generated using generate_mst. The MR11 release requires the following firmware revision levels. Disc: DSC191 -- T1 DSC500 -- R1 MSP800 -- A1 Tape: MTC0500 -- V1 MTP0601 -- R1 MTP0610 -- R2 Firmware Status 3-1 SIB11.0 Unit Record: Common -- P2 Reader/Punch -- B2 PRU1200/1600 -- L1 _F_I_E_L_D _C_H_A_N_G_E _O_R_D_E_R _L_I_S_T The following list of FCOs should be thought of as a continuation of the similar list for MR10.2. A column has been added to the catagory lists, this column will indicate the Multics release period during which the FCO was published. Sites that are upgrading from the MR10.1 and MR10.2 release will need to verify that FCOs for the MR10.2 release have been installed. As FCOs are completed in Phoenix, they are sent out to the field sites. Some of the FCOs affect only site documentation while others may change the hardware to improve system reliability or maintainability. An example might be a change to improve the supply of cooling air to some boards so that the boards run cooler and are therefore less likely to fail. These types of FCOs are important to the long-term success of system operation. However, because these FCOs are not required to correct the results of any computer program, they are not listed in this SRB. The purpose of this section is to identify those FCOs that are of utmost importance in the short term. This list includes only those FCOs needed to correct a program malfunction. For those FCOs already sent to the field, the "FCO Kit Ship Date" column contains the approximate date when shipment of the FCO kits began. One of the column headings in the tables on the following pages is "Round Robin". The implications of a "Yes" in this column for a particular FCO are as follows: 1. The FCO kit includes at least one board. The new board(s) is to replace the board(s) now in the equipment. 2. Enough FCO kits are put together for about 20% of the sites that are to take part in the Round Robin. Some FCOs result in a Round Robin for all sites. Other FCOs involve a Round Robin for some sites but not for other sites. For example, two of the factors that determine whether or not a particular site takes part in a Round Robin FCO are: a. The date codes of certain integrated circuit chips on a board. b. The board construction method -- wirewrap vs. multilayer. Firmware Status 3-2 SIB11.0 3. The set of FCO kits are sent to the first set of sites. (For the remainder of this discussion, we will follow one kit as it makes its Round Robin journey.) 4. The site installs the FCO. When the site is satisfied that the FCO is satisfactory, the site returns the old board(s) to Phoenix. 5. If there is still equipment at other sites that have not had the FCO installed, the returned board(s) is reworked, tested, and another FCO kit is assembled in Phoenix and sent to the next site. 6. Since the length of time it takes a site to install an FCO and become satisfied that it is working correctly cannot be known in advance, there is no way to predict with accuracy how long it will be until the FCO has been installed at all sites. The FCOs have been classified into the following categories: _C_A_T_E_G_O_R_Y__1 - The new software for this release will not run properly unless these FCOs are installed. _C_A_T_E_G_O_R_Y__2 - The new software for this release may or may not run properly if these FCOs are not installed. It is strongly recomended to have these FCOs installed to improve reliability of the system. _C_A_T_E_G_O_R_Y__3 - FCOs whose effects are program-visible, but do not fall into categories 1 or 2. Category 3 FCOs correct problems that are not uniquely related to this release. Firmware Status 3-3 SIB11.0 _P_R_O_M _R_e_v_i_s_i_o_n_s Since the toehold address to crash Multics has changed, the DMP's BOS command is no longer used. Instead, with FCO PHAOPD363 the DMP will accept the BCE command with the octal switch value as the first argument. The argument normally will equal the address of the XED RTB instruction, For example, "BCE 24000" entered on the DMP will return the system to BCE level. For sites that need to revert to a previous release, "BCE 10000" Will cause a return to BOS. With this release it becomes possible for sites utilizing CSU6601 (LCC) consoles, with firmware revision C.0 installed, FCO PHAFKJ113, to enter the admin password on the console without having it echoed to the screen, and any attached monitor. This option is controlled by the "MASK" keyword on the PRPH card describing each console. Please refer to the description of the card in Section 4 for more information. Those sites migrating from MR10.1 to MR11 must ensure that the FCO's listed for migration from MR10.1 to MR10.2 and those listed for migration from MR10.2 to MR11 have been completed. Firmware Status 3-4 SIB11.0 _C_H_A_N_G_E_S _R_E_Q_U_I_R_E_D _F_O_R _M_I_G_R_A_T_I_O_N _F_R_O_M _M_R_1_0_._1 _T_O _M_R_1_0_._2 _C_A_T_E_G_O_R_Y__1__F_I_E_L_D__C_H_A_N_G_E__O_R_D_E_R_S FIELD CHANGE ORDERS VITAL TO THIS SOFTWARE RELEASE Est. FCO Hours for FCO Kit Round To Multics FCO Number Board Ship Date Robin Instl Release ---------- ------ --------- ----- ----- ------- ------------CONSOLE----------------------------------------- PHAFKJ099 CONJK 83 APR Yes 1.0 MR10.2 ------------DPSM CENTRAL PROCESSOR-------------------------- PHAFPD246 ETMPE/CH 83 AUG Yes 1.9 MR10.2 PHAFPD247 ETMBH/PD 83 AUG No 2.5 MR10.2 * Sites with SCUMM boards should contact the TAC Center for information on how to request, via FCO discrepency report, an updated SCUMN board. Firmware Status 3-5 SIB11.0 _C_A_T_E_G_O_R_Y__2__F_I_E_L_D__C_H_A_N_G_E__O_R_D_E_R_S FIELD CHANGE ORDERS POSSIBLY NEEDED FOR THIS RELEASE Est. FCO Hours for FCO Kit Round To Multics FCO Number Board Ship Date Robin Instl Release ---------- ------ --------- ----- ----- ------- ------------DPSM CENTRAL PROCESSOR-------------------------- PHAFPD217 BKPNL 83 JUN No 2.0 MR10.2 PHAFPD224 ETAPD 83 JUN No 1.0 MR10.2 PHAFPD232 ETMCX 83 JUN Yes 1.0 MR10.2 PHAFPD238 ETMBB 83 JUN Yes 1.0 MR10.2 Firmware Status 3-6 SIB11.0 _C_A_T_E_G_O_R_Y__3__F_I_E_L_D__C_H_A_N_G_E__O_R_D_E_R_S FIELD CHANGE ORDERS INDEPENDENT OF A PARTICULAR RELEASE Est. FCO Hours for FCO Kit Round To Multics FCO Number Board Ship Date Robin Instl Release ---------- ------ --------- ----- ----- ------- ------------INPUT/OUTPUT MULTIPLEXER----------------------- PHAFXB135 MQXJN 83 JUL Yes 1.0 MR10.2 PHAFXW151 NSCIK 83 JUL No 2.5 MR10.2 PHAFXW156 NSAJM/NSBJM 83 SEP No 0.7 MR10.2 ------------MEMORY CONTROLLER------------------------------ PHAFMJ311 SCAMM 83 JUL No 1.2 MR10.2 PHAFMJ292 SCAMC/SCAMJ 83 MAY Yes 1.5 MR10.2 ------------MICROPROGRAM CONTROLLER------------------------ PHAFTH034 MT8FX 83 SEP No 1.0 MR10.2 PHAFTH922 MT8FX 83 SEP Yes 1.0 MR10.2 PHAFPV746 MT8FX 83 SEP Yes 1.0 MR10.2 PHAFTG913 MT8WD 83 SEP No 1.3 MR10.2 ------------L68 CENTRAL PROCESSOR-------------------------- PHAOPG192 Bkpnl 83 DEC - - MR10.2 PHAOPG193 645BG 83 DEC - - MR10.2 PHAOPG194 645PX 83 DEC - - MR10.2 ------------DPSM CENTRAL PROCESSOR-------------------------- PHAFPD218 ETMPH 83 JUN No 0.7 MR10.2 PHAFPD221 ETMCM 83 JUN Yes 1.0 MR10.2 PHAFPD222 ETMPF 83 JUN No 1.2 MR10.2 PHAFPD223 ETMCP 83 JUN No 1.4 MR10.2 PHAFPD278 ETMCG 83 SEP Yes 1.2 MR10.2 PHAFPD947 ETMCP 83 JUN Yes 1.0 MR10.2 PHAFPD953 ETMCH 83 AUG Yes 1.0 MR10.2 PHAFPD952 ETMPE 83 AUG Yes 1.0 MR10.2 PHAFPE345 ETCCC 83 SEP No 0.2 MR10.2 PHAFPE928 ETCAD 83 OCT Yes 0.8 MR10.2 Firmware Status 3-7 SIB11.0 _C_H_A_N_G_E_S _R_E_Q_U_I_R_E_D _F_O_R _M_I_G_R_A_T_I_O_N _F_R_O_M _M_R_1_0_._2 _T_O _M_R_1_1_._0 _C_A_T_E_G_O_R_Y__1__F_I_E_L_D__C_H_A_N_G_E__O_R_D_E_R_S FIELD CHANGE ORDERS VITAL TO THIS SOFTWARE RELEASE Est. FCO Hours for FCO Kit Round To Multics FCO Number Board Ship Date Robin Instl Release ---------- ------ --------- ----- ----- ------- ------------INPUT/OUTPUT MULTIPLEXER----------------------- PHAFKJ113 CONJK 85 FEB NO 0.2 MR11.0 PHAFXW201 NSAJM 84 JUN NO 1.5 MR11.0 NSBJM SITES USING NSA IOM'S MUST INSURE OPTION WIOG008A-001 IS INSTALLED TO MAKE PAGED MODE I/O WORK. ------------DPSM CENTRAL PROCESSOR-------------------------- PHAFPD356 ETDCC 84 JUN NO 1.0 MR11.0 Firmware Status 3-8 SIB11.0 _C_A_T_E_G_O_R_Y__2__F_I_E_L_D__C_H_A_N_G_E__O_R_D_E_R_S FIELD CHANGE ORDERS POSSIBLY NEEDED FOR THIS RELEASE Est. FCO Hours for FCO Kit Round To Multics FCO Number Board Ship Date Robin Instl Release ---------- ------ --------- ----- ----- ------- ------------CONSOLE----------------------------------------- PHAFKJ919 KEYS 85 MAR NO 0.3 MR11.0 ----------- IFAD RELEASE B.3 ------------------------------ PHAFGA891 TAPE 85 MAR NO NA MR11.0 ------------MEMORY CONTROLLER------------------------------ PHAFMJ929 SCUMH 84 OCT NO 1.0 MR11.0 PHAFMJ355 SCUMH 84 OCT NO 1.0 MR11.0 PHAFMJ339 SCUMH 84 MAR NO 1.0 MR11.0 PHAFMJ926 SCUMH 84 MAR NO 1.0 MR11.0 ------------MICROPROCESSOR CONTROLLER---------------------- PHAFTH039 MT8BG 84 AUG NO 0.9 MR11.0 ------------L68 CENTRAL PROCESSOR-------------------------- PHAFPG195 645BG 84 JUL NO 1.3 MR11.0 ------------DPSM CENTRAL PROCESSOR-------------------------- PHAFPD358 ETMBL 84 JUN NO 1.0 MR11.0 PHAFPD357 ETMBH 84 JUL NO 1.0 MR11.0 PHAFPE416 ETCCC 84 JUN NO 1.0 MR11.0 PHAFPD350 ETDPX 84 APR NO 1.2 MR11.0 PHAFPD302 ETMCP 84 JAN NO 1.2 MR11.0 PHAFPD354 ETDCX 84 JUN NO 1.2 MR11.0 PHAFPD359 ETMPF/CH 84 JUN NO 1.0 MR11.0 Firmware Status 3-9 SIB11.0 _C_A_T_E_G_O_R_Y__3__F_I_E_L_D__C_H_A_N_G_E__O_R_D_E_R_S FIELD CHANGE ORDERS INDEPENDENT OF A PARTICULAR RELEASE Est. FCO Hours for FCO Kit Round To Multics FCO Number Board Ship Date Robin Instl Release ---------- ------ --------- ----- ----- ------- ------------INPUT/OUTPUT MULTIPLEXER----------------------- PHAFXW181 MQXJT 85 MAR NO 1.0 MR11.0 PHAFXW915 NSAJM 84 JAN NO 0.7 MR11.0 NSBJM PHAFXW178 MQXJA 84 AUG NO 0.5 MR11.0 MQXJP NSAJA NSAJP ------------EMBEDDED UNIT RECORD CONTROLLER----------------- PHAFPD059 EURCB-B 84 JUL NO 1.0 MR11.0 ------------MICROPROCESSOR CONTROLLER------------------------ PHAFTG210 MT8ED 84 JUL NO 1.0 MR11.0 PHAFTG208 MT8AC 84 APR NO 1.0 MR11.0 PHAFBB136 MPCME 84 OCT NO 1.0 MR11.0 MPCSC ROMSE ------------T&D RELEASE REV. D.5----------------------------- PHAFGA890 TAPE 85 MAR YES 2.0 MR11.0 ------------L68 CENTRAL PROCESSOR---------------------------- PHAFMJ356 ML2RP 84 NOV NO 0.8 MR11.0 ML2RQ ML2RR PHAFPG194 BKPNL 84 FEB NO 1.6 MR11.0 PHAFPD304 BKPNL 84 JAN NO 1.3 MR11.0 Firmware Status 3-10 SIB11.0 _C_A_T_E_G_O_R_Y__3__F_I_E_L_D__C_H_A_N_G_E__O_R_D_E_R_S FIELD CHANGE ORDERS INDEPENDENT OF A PARTICULAR RELEASE Est. FCO Hours for FCO Kit Round To Multics FCO Number Board Ship Date Robin Instl Release ---------- ------ --------- ----- ----- ------- ------------DPSM CENTRAL PROCESSOR-------------------------- PHAFPD312 ETDPD 84 APR NO 1.0 MR11.0 PHAFPD307 ETMBB 84 APR NO 2.0 MR11.0 PHAFPD351 ETDAK 84 MAY NO 1.0 MR11.0 Firmware Status 3-11 SIB11.0 SECTION 4 INSTRUCTIONS FOR SITES UPDATING TO MR11 FROM MR10.2 If problems are encountered in any of the Steps listed below, return to the last step known to be successful and retry the Steps. Pay particular attention to procedure. This entire procedure was verified on the Multics System at Phoenix Computer Operations, but some hardware/software differences may exist at a particular site. In this section, two formats of text are used to indicate the typing of input into the system. This input usually is a command line, but could be data typed in response to a query from the operator console. Strings of input, and output messages of importance are indicated on separate lines. In addition, all input to the system is to be typed in lowercase, except when indicated by the occurrence of both uppercase and lowercase in the input line. User input is preceeded by an exclamation mark (!). System display output is shown as is, except when the displayed line exceeds the page margins for this document. When this occurs, the displayed line is split into two lines, with the second line indented from the first. The procedure described in this section is intended for use by sites currently running the MR10.2 release. Sites running MR10.1 should follow the procedures found in "Section 6". SITES USING NSA IOM'S MUST INSURE OPTION WIOG008A-001 IS INSTALLED TO MAKE PAGED MODE I/O WORK. Instructions - Updating 4-1 SIB11.0 ___S___I___G___N___I___F___I___C___A___N___T ___C___H___A___N___G___E___S ___I___N ___T___H___I___S ___R___E___L___E___A___S___E 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. 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 like printer support, are not yet available within BCE. For this reason sites who require this continued level of support are advised to boot the system with the BOS tape provided with the MR11 package. It will then be possible to pass from BOS to the BCE command level or back to BOS from BCE directly. Sites using BCE only, can boot directly from the MR11 Multics System Tape (MST) for normal operation. The installations instructions for this release will assume that BOS is being used. The operation of Bootload Multics is described in detail in the Multics System Maintenance Procedures Manual, 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. With MR11, executing switches to force a manual return to Bootload Command Environment 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. With this release the toehold address to BOS has changed. The DMP's BOS command is no longer used. Instead, with FCO PHAOPD363 the DMP will accept the BCE command with the octal switch value as the first argument. The argument normally will equal the address of the XED RTB instruction, For example, "BCE 24000" entered on the DMP will return the system to BCE level. For sites that need to revert to a previous release, "BCE 10000" Will Instructions - Updating 4-2 SIB11.0 cause a return to BOS. For a better discussion of the changes involved with Bootload Multics, refer to "Appendix A" of this document. With this release the processors (CPUs) will loop and appear to be hung rather than stopping on a DIS instruction as previously had been the case, when an error was detected that couldn't be reported. With this release of firmware the idle pattern in the maintenance panel of the MTP610 or MTP611 will flash at a much faster rate. Expect this as normal. Instructions - Updating 4-3 SIB11.0 _S_T_E_P _1_: _P_R_E_-_I_N_S_T_A_L_L_A_T_I_O_N _P_R_E_P_A_R_A_T_I_O_N The following step can be executed any time prior to the shut down for installation of MR11. This step will create directories and segments used only in MR11. The examples given when setting access to segments and directories will provide the smallest and most restrictive working set. Each site should review the access it wishes to grant. The process that runs the crank, for example should be given correct initial acls to access the system logs. This step may be completed from a terminal where the user is registered with the SysAdmin project or has logged in as Repair.SysDaemon. It is recommended that system personnel examine the new system exec_coms and select files provided with MR11. This can be done prior to starting the installation by doing a cross-retrieve. The system exec_coms can be found on the 11.EXEC tape. A Sample Retrieval: >tools>master.ec=>udd>SiteSA>11.release>11.master.ec The site should review the system_start_up.ec, biller.ec, util.ec, utility_start_up.ec, admin.ec and master.ec to merge any local site changes in with the supplied exec_coms. The system exec_coms have been extensively rewritten. New default report control files are provided to replace log_select_files and syserr_select_file. the files daily_io_log.ssl, daily_admin_log.ssl, daily_syserr_log.ssl and daily_as_log.ssl in >tools should be reviewed and merged with any local site modifications. The perm_syserr_log vfile will no longer be used. All syserr messages have been moved into a new syserr log directory. The directory must be created on the RLV, with appropriate AIM level and quota. The new syserr log consists of 2 segments in >system_library_1, and one or more segments in >system_control_1>syserr_log. By default, the ACL on the segments in >system_library_1 is "r" for the SysDaemon, SysAdmin and SysMaint projects, "rw" for the Initializer and "null" for all other users; this ACL is provided by the hardcore.header. The ACL of >system_control_1>syserr_log must be "s" for anyone allowed to read the log. The Initializer and any process allowed to trim the log must be given "sma" access. The IACL must be "rw" for the Initializer.SysDaemon and "r" for any user allowed to read the log. There is no longer an audit_gate_ to control access. Instructions - Updating 4-4 SIB11.0 A quota should be placed on >system_control_1>syserr_log to limit the effect of run away syserr messages. When quota is exceeded, an Answering service dump is generated and copying will stop. To prepare the new log do the following: create_dir >system_control_1>syserr_log -quota Q Where Q is sufficent quota to hold a reasonable number of log segments. It is recommended that the initial quota be set at 15000 which will hold approximately ten (10) days of syserr logs. For this installation a new PNT and MAIL_TABLE will be created. Before starting the installation ensure that there is sufficent quota to hold the existing segments located in >system_control_1 and >site. For new segments allow a growth factor of 25%. With MR11, all system access control segments will be centralized into one admin_acs directory. Create the directory and set the approperate access according to your system needs. To move the existing system ACS segments to the new directory execute the following: cwd >sc1 rename proxy admin_acs add_name admin_acs proxy set_acl admin_acs sma *.SysAdmin sma *.SysDaemon null * -replace set_iacl_seg admin_acs rw *.SysAdmin rw *.SysDaemon null * -replace copy >system_control_1>**.install.acs >system_control_1>admin_acs>== -all copy >system_control_1>rcp>tandd.acs >system_control_1>admin_acs>== -all The send_admin_command (sac) has been reimplemented. The control segment >system_control_1>communications has been deleted. Access to use this command will be controlled by the new ACS segment >system_control_1>admin_acs>send_admin_command.acs. Execute the following commands to prepare the "sac" command for proper access: cr >system_control_1>admin_acs>send_admin_command.acs copy_acl >system_control_1>communications >system_control_1>admin_acs>send_admin_command.acs set max length to 0 on acs segment. Instructions - Updating 4-5 SIB11.0 For MR11 new ACS segments will be used for Data_Management Daemons. If the site intends to use Data Management, then a bump_user.acs and a process_termination_monitor.acs segment must be created. To create these segments type: cr >system_control_1>admin_acs>bump_user.acs cr >system_control_1>admin_acs>process_termination_monitor.acs These segments should only have access for Data_Management daemons and administrators. See the Data Management Appendix, Appendix C, for more detail. With this release the access to Hexadecmal floating point operations will be controlled by a new ACS segment. If the site intends to use this feature, then a Fortran_hfp.acs segment should be created. See the Fortran Users Guide for more detail. All logs produced by the answering service and message coordinator are now standard system logs. The pathname for log, iolog, vinc_log, vret_log, imft_log and admin_log is >system_control_1>as_logs. Any site defined Daemons that write logs in this directory should be checked for access. To allow continued logging, create the directory as follows: cd >system_control_1>as_logs set_iacl_seg as_logs rw *.SysAdmin rw *.SysDaemon rw *.Daemon null * With this release analyze_multics supports the analysis of dead processes. A new tool, copy_deadproc, copies saved dead process directories into a directory >dumps>save_pdirs. It is recommended that sites create this as a master directory, not on the RLV, from a process with appropriate access and privilege to set mdir quota, as follows: create_dir >dumps>save_pdirs -lv VOL_NAME -quota Q Where Q is sufficent quota to hold a reasonable number of process directories for site investigation. It is recommended that Q be initially set to 10000 records. cwd >dumps>save_pdirs set_acl -wd sma *.SysAdmin sma *.SysDaemon s * set_iacl_dir -wd sma *.SysAdmin sma *.SysDaemon null * Before starting, examine all pmf's for users permitted to login above system_low. They must be changed to include explicit "Authorization" or "authorization" statements with a minimum and maximum access range. For example: authorization: "system_low:system_high"; Instructions - Updating 4-6 SIB11.0 The system is now prepared for the update of MR11. Continue to the next step. _S_T_E_P _2_: _I_N_S_T_A_L_L_A_T_I_O_N _I_N_S_T_R_U_C_T_I_O_N_S Due to the extensive changes to the answering service and administrative databases it is recommended that the site complete_dump, or copy to another safe directory structure, the directories >system_control_1, >site>mail_system_dir, >udd>sa>lib and >udd>sa>a. In the event the installation must be aborted or backed out, a retrieval of these directories and a reload of the executable libraries (i.e.,not system MR11) will allow continued operation with the old release. The directories dumped and the executable libraries can be reloaded with the old systems MST tape at ring 1 with the reload_system_release command. Using the 10.2 BOS System, perform a SAVE. A double save is recommended to avoid any possible tape problems later. With this release two new partitions are required on the rpv for BCE operation. These are the "bce" partition of length 2200 records and the "file" partition of length 255 records. These may be created by use of automatic or manual partition creation. The ability to run without a log partition is removed with this release. Additionally, the LOG partition must be on the RPV. If your LOG is not now on the RPV volume then it will be automatically created when MR11 is booted for the first time. The standard size of the LOG partition is 255 records. Sites that require auditing should consider a larger size LOG partition within the 513 record limit. _A_u_t_o_m_a_t_i_c _P_a_r_t_i_t_i_o_n _C_r_e_a_t_i_o_n The first boot of MR11 is also capable of creating the required BCE partitions. To allow this to work, at least 3000 records (2455 for the new partitions and around 500 for rpv only segments created during later initialization) must be free on the rpv. Using the 10.2 operating system to determine if enough free space exists type: list_vols -pv rpv the second number appearing after the drive name is the records available on rpv. If this number is greater than 3000, MR11 may simply be booted at this time. The required partitions will be created at the high end of the disk, just below any partitions currently at the high end. This generation takes on the order of 10 minutes during this first boot. If there are not enough free records on the rpv, some segments Instructions - Updating 4-7 SIB11.0 will have to be moved to other drives. Use the sweep_pv command to move small collections of segments to other physical volumes in the RLV until enough free space exists. _M_a_n_u_a_l _P_a_r_t_i_t_i_o_n _C_r_e_a_t_i_o_n The required partitions may also be created manually, using rebuild_disk performed with the 10.2 system. Before starting the rebuild_disk of the rpv, it will be necessary to add to the config deck's parm card: PARM DIRW Sites that don't normally run with the "dirw" parameter should remove this from the config after the rebuild_disk is complete. Assume that the rpv is mounted on dska_01 and a scratch pack is mounted on dska_02. Boot, using the 10.2 Multics System Tape (MST), not the MR11 MST, to ring-1 command level by executing the following: boot N (where N is the drive number of the 10.2 MST) rebuild_disk rpv dska_01 -copy dska_02 The rebuild_disk command will report information about the size of the partitions found on the source rpv. This information should be noted for use when constructing the new partitions on the target rpv. The rebuild_disk command will prompt for input, at this point the new partition layout should be entered as in the example that follows: request: part alt high 141 (on MSU451/400 only) request: part bos high 270 request: part log high 256 request: part dump high 2000 request: part file high 255 request: part bce high 2200 request: part hc low 2500 request: part conf low 4 request: nvtoce request: list request: end When the rebuild_disk is complete, shutdown and boot with the new rpv located on dska_02. For sites with MSU500 type units, the BOS SAVE COPY command can be used to move the temporary RPV back to the original device. Instructions - Updating 4-8 SIB11.0 _S_T_E_P _3_: _P_R_E_P_A_R_A_T_I_O_N _F_O_R _M_R_1_1 _I_N_S_T_A_L_L_A_T_I_O_N It will not be possible to boot with the old release after this step is complete. The site should run the crank one last time to clean up as much of the system before shut down. Be sure the Root volumes contain enough space for growth. See "Automatic Partition Creation" under "Step 2". A save of the systems administrative directories should be done as outlined in step 2. We are now ready to shutdown and re-boot for the last time on the 10.2 release. To do this go through the procedure established at your site for normal shutdown. Boot using the Multics System Tape (MST) for MR10.2 to Initializer ring-1 command level and type: boot N (where N is the drive number of the 10.2 MST) alv -all standard admin The following will prepare the system for conversions which will follow: set_acl >lv sma *.SysAdmin sma *.SysDaemon create_dir >lv.mr10 set_acl >lv.mr10 sma *.SysAdmin sma *.SysDaemon To exit admin mode and continue on to the next step type: ame mult (starts answering service) go (in special session.) For MR11 a new volume registration database will be created. User access to a private logical volume will be computed using the ACS pathname contained in the volume registration database. The links that existed in past releases under the directory >lv will no longer be used, the control segments will be moved into the directory. The following sequence will need to be executed from a privileged process in Ring 1. WE RECOMMEND USING Ring_1_Repair.SysDaemon AND EXECUTE THE FOLLOWING INSTRUCTIONS: cwd >lv unlink lv.root unlink lvid.!* unlink pv.** unlink pvid.!* unlink root.mdcs Instructions - Updating 4-9 SIB11.0 Save the MR10 versions of the registration information. copy >lv.** >lv.mr10>== -nm Move the master directory data into >lv. copy lv list **.acs -all -sort print_config_deck Due to the method by which unbundled software is dumped, normal trimming during reloading of new software does not occur. To ensure that unbundled directories are clean execute the following: cwd >system_library_unbundled answer yes -bf hpdl ([files **]) cwd >library_dir_dir>unbundled>source answer yes -bf hpdl ([files **]) cwd >library_dir_dir>unbundled>object answer yes -bf hpdl ([files **]) To shut the system down and continue to the next step type: ame shutdown Instructions - Updating 4-10 SIB11.0 _S_T_E_P _4_: _I_N_S_T_A_L_L_A_T_I_O_N _O_F _B_C_E This step involves booting BCE for the first time. If the partitions were not created manually as described in Step 2 they will be created automatically during this step. These partitions are required for BCE. A complete description of the procedure for booting BCE can be found in the Multics System Maintenance Procedures Manual, AM81. A sample dialog with user input preceded by an exclamation point (!) follows: Place the MR11 BOS TAPE on any convenient drive, set the MPC switches to reflect this tape drive, and initiate the INITIALIZE/BOOT sequence of the IOM. The system will then proceed in the manner shown below. Start by loading all the controllers on the system with the new firmware. Do this for each controller you have configured: ENTER TAPE CONTROLLER TYPE: FWLOAD-> ! t601 BOOTING T601 on IOM A CHN 21 BOOTED t601 WITH M601 REV.N1 FIRMWARE. FWLOAD-> ! d451 a 22. BOOTING D451 on IOM A CHN 26 BOOTED D451 WITH M191 REV.P1 FIRMWARE. Proceed by loading out the MR11 BOS into the BOS partition: FWLOAD-> ! cold 451. 22. 1 BOS PARTITION AT 37847. FOR 270. BOS MR11 at 18:19:17 EST WED 7/18/84 BOS-> ! config l {conf1} Place the new MR11 MULT tape on any convenient tape drive. For our example we will be using drive 2, to boot into the new ring-0 environment: BOS-> ! boot 2 BOOTING TAPE MULT bootload_0: Booting system MR11 generated 11/01/84 0000.0 1620.1 announce_chwm: 353. pages used of 512. in wired environment. 1620.2 announce_chwm: 626. words used of 1024. in int_unpaged_page_tables. 1620.4 init_root_vols: Adding bce file partitions to rpv. 1622.0 load_mst: 627. out of 1048. pages used in disk mst area. bce (boot) 1623.5: At this time, bce has been booted. Instructions - Updating 4-11 SIB11.0 _S_T_E_P _5_: _C_H_A_N_G_E_S _T_O _C_O_N_F_I_G _D_E_C_K To examine and change the config deck enter the config qedx editor by typing: config 1,$p to display the entire config deck as currently saved in the "conf" partition. It is now necessary to determine whether changes need to be made to the config deck. Particular attention should be given the PRPH OPC, FNP, IOM, and PARM cards. This is done as follows: Changes have been made to the console software and firmware to support unechoed reads from the console. With this release it becomes possible for sites utilizing CSU6601 (LCC) consoles, with firmware revision C.0 installed, FCO PHAFKJ113, to enter the admin password on the console without having it echoed to the screen or any attached monitor. This option is controlled by the "MASK" keyword on the PRPH card describing each console. If C.0 firmware and FCO PHAFKJ113 have not been installed the site MUST use the "MASK" keyword. The next line shows proper syntax for the PRPH OPC card: PRPH OPC {MASK} NOTE: The MASK field doesn't apply for EMC style consoles. EMC consoles will always be set to mask the password regardless of the MASK field state on the card. The "FNP" config card is eliminated from the config deck. The fnp will be defined on the prph cards. Add the following prph card for each of the FNPs: PRPH FNP IOM CHANNEL MODEL STATE Where the FNP is a letter (A through H). The CHANNEL field must be valid and if decimal must be followed by a period (e.g., 13.). The MODEL field must be a valid model number followed by a period (e.g., 6670.). The 6670. model designation is valid for either the 355 or 6678 FNP type. The STATE field must be either on or off. An "ON" specifies that the FNP can be loaded by the answering service if the CMF calls for it to be loaded. An "OFF" state specifies that the FNP may not be loaded by the answering service even if the CMF calls for it to be loaded. One card should be inserted into the config deck for each FNP. With this release, all IOMs must be operated in paged mode. The operating mode switch on the IOM must be set to "PAGED" and the model field on all IOM cards must be "NSA". A new field is now provided on the PARM card to improve disk Instructions - Updating 4-12 SIB11.0 performance. The default value for the new parameter DSKQ is as follows: wlim for each 451 = 20 wlim for each 501 = 80 If WLIM has been used at the site, then set DSKQ to 150% of the WLIM value, if it is more then the total of the default value. The WLIM parameter on the PARM card is no longer honored and may be removed. The new tune_disk command functionally replaces this parameter. The ASTK parameter on the PARM card is no longer honored and may be removed. Generation of sst_names_ will now be generated in the bce_dump program. IOM switches can optionally be validated for consistency when the device is added to the system by adding the RICS parameter to the PARM card in the config deck. Sites using "PARM DIRW" in the configuration should remove this parameter during the tape loading phase. This significantly speeds up the reloading of tapes. This parameter should be inserted again when the system is rebooted. At this point check the part cards to ensure LOG partition is on the RPV. After having made necessary changes exit the editor and type reinit The "w" request will verify card syntax. The "q" request will leave the qedx editor and place the user at the bce(boot) level. Typing "reinit" at bce(boot) forces changes to the config deck to be saved in the "conf" partition. _S_T_E_P _6_: _R_I_N_G_-_1 _E_N_V_I_R_O_N_M_E_N_T The system is now ready to cross into the ring-1 environment: bce (boot) 1200.5: boot Multics MR11 - 11/02/84 1201.0 est Fri. Command: Users should expect the console to report the following messages: init_syserr_log: Converting MR10.2 syserr partition init_syserr_log: Syserr LOG partition reinitialized volume_registration_mgr_$check volume_registration: Converted ">lv>lv.root to version 2. (Initializer.SysDaemon.z) The message will be given for each logical volume. Instructions - Updating 4-13 SIB11.0 At Initializer ring-1 command level, type: alv -all At this point the libraries will be reloaded. The release tapes should be reloaded in this specific sequence: EXEC, LDD_STANDARD, UNB, and MISC. To complete the library reload type: reload_system_release -nosetlvid When the system asks "Input tape label:" type: where is the reel identification specified for the next tape to be reloaded. See Section 2, "Contents of MR11 Package," for a listing of all "Tape names". Repeat this step for each library tape. When all tapes are loaded, type: standard admin The system will enter admin mode without the need of a password the first time it is used with MR11. The old password from communications is NOT automatically copied, you must set it after converting and setting access for the PNT. The following will move all syserr messages from the ring zero LOG partition and the >system_control_1>perm_syserr_log vfile into the new syserr log directory. convert_syserr_log >system_control_1>syserr_log In MR11, the answering service logs, message coordinator and syserr logs have been converted to a common format. New commands have been added to manipulate the logs. The convert_old_log command will change existing logs to the new format. If you want to save the information in the answering service log or message coordinator log, execute the following: answer yes -bf convert_old_log LOG_NAME Where LOG_NAME can be log, iolog and any other site-define message coordinator logs. If your history directory is not >udd>sa>a>history, you need to type: convert_old_log LOG_NAME -ohd HISTORY_DIR_PATH If you want to use a directory other then >udd>sa>a>history as the first place old logs are put, use the -nhd argument. You Instructions - Updating 4-14 SIB11.0 must include this change in the new master.ec if used. The following commands should be executed to re-structure the answering service tables. convert_MR10_2_sat sat convert_MR10_2_pdts pdt convert_MR10_2_pnt PNT The PNT is now called PNT.pnt and is a Ring-1 database. Using the set_acl command set the access on the new PNT.pnt for only those users requiring access to the PNT. The minimum access for correct system operation is rw for Initializer.SysDaemon and *.SysAdmin and r access for *.SysDaemon, IMFT.*.z, and Card_Input.Daemon. In addition the site can add access for any site-defined daemons which handle remote-io, card-input, and IMFT if the names differ from the ones specified in the example. To set the admin password, execute the following: set_special_password operator_admin_mode Password Where XXX is the admin password of your choice. The password is not echoed and the user is not asked for password verification. If you do not wish a password, do the following: set_special_password operator_admin_mode -none Many new parameters are provided with this release. The ed_installation_parm command must be invoked at this time to reset the version number. Additional changes will avoid warning messages when operation continues. The segment >system_control_1>communications will no longer be used. The size of the process directory is now an installation parameter. The following values are recommended: ed_installation_parms c log_parameters 10 (set the syserr log copy interval) c default_pdir_seg_quota 1000 (size of seg quota limit) c default_pdir_dir_quota 1000 (size of dir limit) w q cwd >udd>sa>a convert_MR10_2_sat smf.cur.sat convert_MR10_2_reqfile reqfile convert_MR10_2_projfile projfile convert_MR10_2_pdts safe_pdts convert_MR10_2_urf URF Instructions - Updating 4-15 SIB11.0 convert_MR10_2_use_totals ([segs **.use_totals]) The administrative exec_coms have been converted to V2 exec_coms. The uses of the old value command have been converted to the new value_set and value_get commands. The convert_old_value_seg command is provided to recover the data in the existing value segment. To convert the old value segment, execute the following: convert_old_value_seg >udd>sa>lib>value_seg >udd>sa>lib>sys_admin.value link >udd>sa>lib>sys_admin.value A value used by the crank to determine the last time the logs were processed needs to be set. Execute the following command to pre-set the value. value_set -pn sys_admin last_log_time [clock calendar_clock] where [clock calendar_clock] is of the form: YYYY-MM-DD__HH:MM:SS:NNNNNN_gmt_Thu. where YYYY is the year, MM is the month, DD is the day, HH is the hour, MM is the minute, SS the second, NNNNNN is the micro second, gmt can be ANY time zone, and Thu can be any alpha day description. The system mail table will be converted due to a change in format with this release. Execute the following command: convert_MR10_2_mail_table >site>mail_system_dir>MAIL_TABLE The convert_MR10_2_mail_table does not copy ACLs. Setting of MAIL_TABLE access is described in Step 9. The format of the coordinator's working tables has been changed. To assure that the coordinator is operating correctly in MR11.0 it is necessary to delete the coordinator directory at this time. When the Coordinator is logged in and attempts to access information in this directory, the directory will be automatically regenerated. Execute the following command: dd >ddd>idd>coord_dir -force The following system exec_coms have been modified for this release. Sites should have reviewed the changes and merged local modifications in with the changes provided with this release. Sites not needing to make any futher modifications should execute the following commands. Sites with modifications to the default exec_coms should replace the pathname to the shipped source with a pathname to the sites modified exec_com. Instructions - Updating 4-16 SIB11.0 answer yes -bf cp >tools>system_start_up.ec >system_control_1>== -update answer yes -bf cp >tools>admin.ec >system_control_1>== -update answer yes -bf cp >tools>util.ec >udd>sa>lib>== -update answer yes -bf cp >tools>master.ec >udd>sa>lib>== -update answer yes -bf cp >tools>err.ec >udd>sa>lib>== -update answer yes -bf cp >tools>biller.ec >udd>sa>lib>== -update answer yes -bf cp >tools>utility_start_up.ec >udd>SysDaemon>Utility>start_up.ec -update Use of the -update control argument makes it necessary to have write access to the various exec_coms. New default report control files are provided to replace log_select_files and syserr_select_file. the files daily_io_log.ssl, daily_admin_log.ssl, daily_syserr_log.ssl and daily_as_log.ssl in >tools should have been reviewed and merged with any local site modifications. If the site will run with the default values, the following should be executed: copy >tools>*.ssl >udd>sa>a>== _S_T_E_P _7_: _F_N_P _C_O_R_E _I_M_A_G_E_S _A_N_D _C_M_F _C_O_N_V_E_R_S_I_O_N A Multics Communications System (CS) core image is supplied in the >unbundled library, and is named "site_mcs". The "site_mcs" core image contains the basic support for DN6780 type FNPs with 64k of memory. CS core images are built using the bind_fnp command in conjunction with a bindfile describing the CS modules and configurations to be used. A copy of the site_mcs.bind_fnp can be found in >ldd>mcs>info. Sites should build their own CS core image tailored to their own FNP configuration, terminal type requirements, and use of additional separately priced FNP software modules. Sites using the default "site_mcs" core image should skip to Step 8 after ensuring the CMF image statement points to the core image now located in >unb. To build a new core image, the following procedure is suggested: Sites will need to extract the communications object segments from archives located in >ldd>mcs>object. Sites should create a virgin directory under >udd>sa>a for each new core image. The following example is for sites with the more common type Datanet and a larger memory configuration. Execute the following commands: Instructions - Updating 4-17 SIB11.0 create_dir >udd>sa>a>mcs.7.3 cwd >udd>sa>a>mcs.7.3 qx r >ldd>mcs>info>site_mcs.bind_fnp (or location of sites CS bind file) . . . make editing changes if any.. . . . w site_mcs.bind_fnp q ac x >ldd>mcs>o>([segs >ldd>mcs>o>*.archive]) bind_fnp site_mcs -list Be sure the image statement in the CMF points to this newly created CS core image. The name of the CMF requires a suffix of "cmf". The following example assumes the CMF to be in the >udd>sa>a directory. This procedure will insure that the new CS image is used: cwd >udd>sa>a qx r CMF.cmf . . 1) Edit the image: statement to point to the new CS image. 2) Replace any use of the check_acs flag for a channel with the appropriate per-channel statement: check_acs: login,slave_dial,dial_server,priv_attach,dial_out; 3) Replace any "access_class: ACC;" statements with: access_class: "MIN_ACC:MAX_ACC"; The new format is a range. For dial_out and slave lines the minimum authorization (MIN_ACC) must be equal to the maximum authorization (MAX_ACC) (i.e. access_class: "system_low:system_low";) 4) Make any other changes needed. . . w CMF.cmf q cv_cmf CMF copy CMF.cdt >system_control_1>cdt -force Instructions - Updating 4-18 SIB11.0 The above procedure builds a site dependent CS core image and ensures that this image is loaded in the FNP by the answering service. _S_T_E_P _8_: _T_T_F _C_O_N_V_E_R_S_I_O_N A new standard TTF has been provided containing additional terminal types. Sites using a modified site dependent TTF should merge these changes with their modified version, and convert the TTF to its binary version. The converted binary version must then be installed to take effect. The TTF.ttf segment in >tools contains some of the more common used terminals on Multics. Sites using the default TTF for this release must execute the following commands to perform this conversion: cwd >udd>sa>a rename TTF.ttf TTF.save cp >t>TTF.ttf cv_ttf TTF install TTF.ttt Exit admin mode by typing "ame". Then issue the commands: stop_mpx a (sites with multiple FNPs execute this command for each FNP) multics load_mpx a -check (sites with multiple FNPs execute this command for each FNP) go The load_mpx command indicates on the FNP console any configuration errors if console_man is loaded and "console: yes;" is in the bind_file. If any errors are reported they should be corrected. Sites should assure the correct version number is reported the first time the FNP is booted. _S_T_E_P _9_: _A_C_L_S _A_N_D _R_I_N_G _B_R_A_C_K_E_T_S Setting of MAIL_TABLE access can be completed by doing the following (user typed commands are preceeded by an exclamation mark (!): M-> ! login Retriever.SysDaemon cd1 --> M-> ! r cd1 cwd >site>mail_system_dir --> cd1 M-> ! r cd1 sa * rw * -replace -no_sysdaemon --> cd1 Instructions - Updating 4-19 SIB11.0 M-> ! r cd1 logout which will provide necessary access to use MAIL_TABLE. Check library access and correct any ACLs or ring brackets which are not appropriate. With this release access to the PNT is controlled with new gates, we recommend the following as the absolute minimum to allow correct system operation. >t>pnt_admin_gate_ re *.SysDaemon.* re *.SysAdmin.* >t>pnt_fs_gate_ re *.*.* >t>pnt_login_gate_ re Initializer.SysDaemon.* re *.SysAdmin.* >t>pnt_network_gate_ re Initializer.SysDaemon.* re IMFT.Daemon.* re Card_Input.Daemon.* re *.SysDaemon.* >t>pnt_priv_gate_ re Initializer.SysDaemon.* r *.SysDaemon.* re *.SysAdmin.* Check the ACLs for >sss>dm_admin_gate_, >sss>dm_daemon_gate_, >tools>installation_tools_, >tools>pnt_admin_gate_, >tools>pnt_network_gate_, >sss>metering_gate_ and >sss>queue_admin_. The ACLs on these gates are as they appear on System M and should be restricted. The ACL for these gates are site dependent and should be changed to meet each site's needs. The dm_admin_gate_ and dm_daemon_gate_ should be restricted to data management administrators or daemons. The installations_tools_ gate should be restricted to system library maintainers. The pnt_admin_gate_ and pnt_network_gate_ should be restricted to system administrators. All persons on the ACL for metering_gate_ have access to the Multics metering data. All persons on the ACL for queue_admin_ are permitted to move absentee and daemon requests for themselves and other users to different queues. Users not on this ACL are only able to move their own requests. The Initializer must have access to queue_admin_. This capability is also dependent on extended access to the .ms segments. Instructions - Updating 4-20 SIB11.0 _S_T_E_P _1_0_: _V_O_L_U_M_E _I_N_F_O_R_M_A_T_I_O_N _A_N_D _O_P_E_R_A_T_O_R _L_O_G_I_N _A_N_D _L_O_G _C_O_M_M_A_N_D_S From a privileged process check the volume registration for the volumes listed in STEP 3. Add ACS path names to the volume registration as necessary. lvr -lv LVNAME cvr -lv LVNAME -acs_path PATH>LVNAME.acs In order to avoid directory quota problems when adding new projects in the future, it is necessary to provide directory quota to >user_dir_dir (>udd). This is done by typing: sac move_dir_quota >udd 100000 A number of undocumented initializer commands have been removed or changed. The MR11 documentation is accurate. The "list_requests" initializer command will show the MR11 commands available. At the initializer console type: list_requests Operator login facilities have been added. Persons with the new "operator" attribute in the PNT may use the sign_on and sign_off initializer commands to log in on the bootload console and/or initializer terminal(s). An installation_parm, require_operator_login, is provided to require that the operator log in before being permitted to enter commands. The default is to set this parameter off. To sign on as an operator, you must have the "operator" flag turned on in your PNT entry. You can require operators to log in with the require_operator_login installation parameter. By default this parameter is off. to turn on the operator flag: new_user$cga USER_NAME flags operator To print logs, use the print_sys_log command: print_sys_log -syserr for the syserr log print_sys_log -as for the answering service log print_sys_log -admin for the admin log print_sys_log -mcl LOG_NAME for a message coordinator log named LOG_NAME i.e. print_sys_log -mcl iolog to print the default I/O log. To monitor logs, use the monitor_sys_log with same control arguments. Instructions - Updating 4-21 SIB11.0 To produce sorted reports in the style of the now obsolete daily_log_process command, use the summarize_sys_log command. To move log segments from one place to another whle preserving the records that link together sets of segments, use the move_log_segments command. If you move them with the standard move command you will destroy the record of previous log segments. If the site has ordered forum see Step 12 before normal service is started. At this point installation of MR11 is complete. Normal service can be now started. The format of the directory information for directory quota has changed. It is suggested that the following exec_com be run from a privileged process after service is continued. Directory quota's are not validated at this time, but will be implemented in a future release. following command line will correct the directory quota values. ec >t>fix_dir_quota_used > -bf _S_T_E_P _1_1_: _S_Y_S_T_E_M _C_L_E_A_N_U_P After the system has been operational for a reasonable period of time, the old segments no longer required can be cleaned up. dl >system_control_1>rcp>tandd.acs dl >system_control_1>rcp>process_termination_monitor.acs dl >system_control_1>sat.install.acs dl >system_control_1>mgt.install.acs dl >system_control_1>rtdt.install.acs dl >system_control_1>cdt.install.acs The old PNT and MAIL_TABLE can now be deleted: dl >system_control_1>PNT dl >site>mail_system_dir>MAIL_TABLE.!* Additional cleanup can be done once the system is up and a reasonable time period has passed: dl >system_control_1>perm_syserr_log dl >system_control_1>sc.message dl >system_control_1>communications dl >udd>sa>lib>log_select_file (unlink in >udd>sa>a) dl >udd>sa>lib>syserr_select_file dl >udd>sa>lib>value_seg dl >system_control_1>tape.message The old >lv.mr10 directory should be deleted in 2 steps, Instructions - Updating 4-22 SIB11.0 1. ldl >lv.mr10>** 2. answer yes dd >lv.mr10 (in Initializer process) 3. ldl >lv.root; ldl >root.mdcs (in Initializer process) 4. unlink >lv>**.acs (in Initializer process) _S_T_E_P _1_2_: _F_O_R_U_M _I_N_S_T_A_L_L_A_T_I_O_N This step is necessary only for those sites ordering the Forum Product. Check the ACLs for >unb>forum_admin_ and >unb>forum_data_ (if the site ordered the Forum product). All persons on the ACL for forum_admin_ are able to use the forum_admin command to tailor operation of the Forum facility and to manipulate meetings chaired by other users. Site persons wishing to change the global forum parameters with the forum_admin command, will also need write access to >unb>forum_data_. Forum meetings should be converted to Version 2 format at the site's convenience. One meeting, Meetings_Directory.control in >site>forum_dir must be converted before service is started to allow the forum announce_meeting command to function correctly. To convert this meeting enter admin mode and type: convert_forum >site>forum_dir>Meetings_Directory.control This command converts the Version 1 meeting to a Version 2 meeting named Meetings_Directory.forum. We recommend that each site convert all of its forum meetings to version 2. Because version 2 forum supports version 1 meetings, this conversion need not be done as soon as MR11 is installed. The site-wide conversion tools consist of the three exec_coms installed in >unbundled called forum_find_v1, convert_meetings, and update_links. Info segments for all three exec_coms are supplied. The forum_find_v1 exec_com is run first to produce two lists: a list of all version 1 meetings in a hierarchy, and a list of all directories containing links to version 1 meetings. Next, the convert_meetings exec_com is run to convert all of the meetings to version 2. Finally, the update_links exec_com is run to update user's links to Version 1 meetings so that meetings are not lost in the conversion process. Each of these will produce error files should any errors occur. Most errors are not serious and the conversion pass can continue. Errors may then be corrected and a second pass run. For example: 1. ear >unb>forum_find_v1 -limit 10000 -ag > (finds v1 meetings and links and creates files MEETINGS, LINKS, MEETING_ERRORS, LINK_ERRORS, ERRORS) Instructions - Updating 4-23 SIB11.0 Examine error files for serious errors. Most will be due to no access and should not be considered serious. 2. ec >unb>convert_meetings MEETINGS (converts all meetings listed in MEETINGS to V2. Creates file CONVERT_ERRORS.) 3. ec >unb>update_links LINKS (updates all links listed in LINKS. Creates file UPDATE_ERRORS) Examine all error files, make appropriate corrections and run a second complete pass by repeating 1, 2 and 3. Conversion of meetings to V2 can be done after MR11 is installed and is not necessary to run MR11. Conversion can be done while normal service is running, but we recommend it be done during an off shift. None of these exec_coms force access to user's hierarchies. We suggest running the exec_coms in a privileged process such as Repair.SysDaemon and notifying users through the message-of-the-day that they should either grant or deny this process access as they feel appropriate. Instructions - First Time 4-24 SIB11.0 SECTION 5 INSTRUCTIONS FOR SITES INSTALLING FOR FIRST TIME The following basic procedure must be performed when installing Multics for the first time. _S_T_E_P _1_: _P_R_E_P_A_R_A_T_I_O_N Ensure that all Multics active hardware components run error free in Multics mode using the latest T&D release. Peripheral equipment can be run in either Multics or GCOS mode and must also run error free. Carefully check the hardware configuration (port and channel assignments, mailbox switch settings, etc.) Create and verify the configuration description on paper for later input when BOS is running. Close consultation between the SiteSA and Field Engineering representative is of the utmost importance. (Refer to Sections 3 and 6 of the MOH manual for information describing hardware switch settings and configuration setup.) It is strongly recommended that a terminal be hardwired via the FNP for use as an initializer console. When selecting the storage unit for the RPV, select a disk unit with as few bad tracks as possible. For the MSS451s, T&Ds should be used to format and test the first disk to be used as the RPV (test 365, subtest 26). The MSS500/501s are formatted at the factory, however, selection of alternate tracks is not done at the factory. It can only be done using MTR at Multics command level. (Refer to Appendix D for an outline of how MTR runs under Multics.) Instructions - First Time 5-1 SIB11.0 _S_T_E_P _2_: _L_O_G_I_C_A_L _V_O_L_U_M_E _A_S_S_I_G_N_M_E_N_T_S Choose the logical volume assignments. Decide how many logical volumes are needed and how many physical volumes are to be in each. Most installations have the following: Logical Volume Contents root >system_control_1 >system_library_standard >system_library_tools >system_library_unbundled >system_library_auth_maint >system_library_1 >documentation >daemon_dir_dir >dumps >system_library_tandd >system_library_obsolete >system_library_3rd_party >site >lv partitions public >user_dir_dir >process_dir_dir >library_dir_dir>include ldd >library_dir_dir Other logical volumes may be set up for specific applications. The assignment decision requires the system administrator to balance the costs of seek interference and breakage against the advantages of being able to define and process logically different collections of data. Data bases used for only a few hours a day or only a few days a month are natural candidates for allocation to a separate logical volume. Breaking up the system's storage into several logical volumes also allows the site to operate without all logical volumes mounted if hardware goes down. For example, an MPC or channel might go down, halving the system's disk drive capacity. Instructions - First Time 5-2 SIB11.0 Logical volume assignments might be as follows: Logical Volume Contents root >system_library_tandd >library_dir_dir >system_library_obsolete >system_library_standard >system_library_tools >system_library_unbundled >system_library_3rd_party >daemon_dir_dir >documentation >dumps >system_library_1 >system_library_auth_maint >user_dir_dir>Daemon >user_dir_dir>SysAdmin >user_dir_dir>SysDaemon >user_dir_dir>SysMaint >site >lv partitions Mcc >user_dir_dir>Mcc Multics_Pubs >user_dir_dir>Pubs >user_dir_dir>Multics Old_Dumps >dumps>Old_dumps Public >user_dir_dir >experimental >process_dir_dir >ldd>include list_1 >library_dir_dir>listings>hard >library_dir_dir>listings>bos >library_dir_dir>mcs >library_dir_dir>unbundled list_2 >library_dir_dir>listings These particular assignments give a wide range of flexibility and Multics can run with only the root logical volume mounted, or with one or two of the less critical logical volumes not mounted due to unavailability of disk drives. For example, logical volumes, list_1 and list_2, can easily be demounted. This frees two disk drives to be available for use with other more critical logical volumes. Instructions - First Time 5-3 SIB11.0 Installations that wish to use the Access Isolation Mechanism (AIM) by specifying more than one access category (sensitivity level) should specify the maximum and minimum categories for one or more volumes and thus ensure that sensitive data is confined to a few packs, or that packs are not "contaminated" with information requiring special precautions. The logical volumes that hold process directory segments must be chosen. Because of the heavy usage of process directory segments, these segments should be spread over as many physical volumes as possible. One or more logical volumes may be selected to hold process directory segments, using the set_pdir_volumes command in system_start_up.ec. In the supplied system_start_up.ec, a single logical volume, named public, is selected. This command line should be changed to select a set of publicly accessible and permanently mounted logical volumes containing as many physical volumes as possible, subject to some constraints. Site maintenance personnel are responsible for ensuring there is always enough space available on the selected logical volumes to hold the process directory segments. The process directory placement algorithm causes process directory creations to be made on each logical volume in proportion to the number of physical volumes in the logical volume. Ensure that enough storage will be available. About 5% of each volume is used for the VTOC and volume map. In addition, some breakage is unavoidable. Since the system handles running out of storage without crashing, and since it is possible to add physical volumes to a logical volume dynamically, logical volumes can be defined with fewer physical volumes than their maximum anticipated size. _S_T_E_P _3_: _R_P_V _I_N_I_T_I_A_L_I_Z_A_T_I_O_N 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 bootload_0: Enter boot tape MPC model: ! t500 Normal response to this question should be "t610", "t601" or "t500". 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. Instructions - First Time 5-4 SIB11.0 0000.1 announce_chwm: 371. pages used of 512. in wired environment. 0000.2 announce_chwm: 646. words used of 1024. in int_unpaged_page_tables. find_rpv_subsystem: Enter RPV data: M-> ! query find_rpv_subsystem: Enter RPV subsystem base channel, as Icc, or "cold". M-> ! cold find_rpv_subsystem: Booting cold will destroy all data on the RPV Are you sure that you want to boot cold? M-> ! yes find_rpv_subsystem: Enter RPV subsystem base channel, as Icc. M-> ! a22 find_rpv_subsystem: Enter RPV subsystem MPC model: M-> ! 451 find_rpv_subsystem: Enter RPV disk drive model: M-> ! 451 find_rpv_subsystem: Enter RPV drive device number: M-> ! 1 find_rpv_subsystem: RPV is a model 451 drive, number 1 on MPC A22 (Model 3), and this is a COLD boot. Is this correct? M-> ! yes 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. request: M-> ! end 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 Multics Administration, Maintenance, and Operations Commands Manual, Order Number GB64-00, prior to the installation. Sizes for the various partitions and their locations can be modified based on the needs of the site. init_empty_root: Begin rpv initialization. This will take some time. init_empty_root: rpv initialized; 27840 records. bce (early) 0010.2: M-> _S_T_E_P _4_: _C_O_N_F_I_G_U_R_A_T_I_O_N Build the configuration description as follows (user input preceeded by an exclamation mark (!): Instructions - First Time 5-5 SIB11.0 ! config ! 1,$d ! a ! [User types in configuration fields as defined in the System Maintenance Procedures, Order Number AM81-03] ! \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. bce (early) 0020.0: M-> ! bce Current system time is: Monday, April 29, 1985 13:13:46 mst Is this correct? no Enter time: M-> ! 04/29/85__13:21:30 Current system time is: Monday, April 29, 1985 13:21:30 mst Is this correct? M-> ! yes load_disk_mpcs: Disk mpc(s): mspa mspc appear not to be operating. Enter disk mpc names to be loaded, or "none" or "abort" or "all": M-> ! mspa mspc (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: M-> 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 : M-> ! boot -cold Do you really wish to boot cold and there by destroy the system hierarchy? M-> ! yes 1201.1 volume_registration_mgr_$check_volume_registration: Reregistered public LV root LVID 133353533031 (Initializer.SysDaemon.z) 1201.3 volume_registration_mgr_$check_volume_registration: Reregistered PV rpv PVID 133353533017 in LV root (Initializer.SysDaemon.z) disk_table_: New disk_table created Multics MR11 - 04/29/85 1202.0 mst Mon. Command: M-> Instructions - First Time 5-6 SIB11.0 Ignore the messages prefaced by disk_table_ and volume_registration_mgr_. _S_T_E_P _5_: _I_N_I_T_I_A_L_I_Z_I_N_G _R_O_O_T _V_O_L_U_M_E_S Initialize each new root volume except the RPV with the init_vol command. For better performance, it is advisable to place a hardcore partition (hc) on each physical volume of the Root Logical Volume (RLV). The placement of the hardcore partition on each volume must be low. The recommended size of additional partitions is 2500 records divided by the number of physical volume used. The RPV size should remain 2500 records to allow the system to boot with only an RPV mounted. For most volumes the command looks like: init_vol PV_NAME DRIVE_NAME -rlv {-special} Example: init_vol root2 dska_02 -rlv -special For those volumes that are to have partitions, or an average segment length other than the default of five records, add the optional "-special" as a third argument. The command then asks for instructions about the partition location. Hardcore partitions, for additional root volumes, should be specified as they are initialized. You may type one or more of the following (see Step 5 for examples): part NAME low nrec part NAME high nrec avg fff.ff list complete initialization by typing: end An example of typing the init_vol for an MSS0451/400 with an alternate partition on a RLV drive is: init_vol root2 dska_02 -rlv -special part alt high 141 part hc low 1000 end when done type: shut Instructions - First Time 5-7 SIB11.0 _S_T_E_P _6_: _A_D_D_I_T_I_O_N_A_L _C_O_N_F_I_G_U_R_A_T_I_O_N _P_A_R_A_M_E_T_E_R_S At bce (boot) level enter the configuration deck editor by typing "config". The PART cards and ROOT card should be added to the deck. Subsequent boots divide the hardcore supervisor among all hardcore partitions as initialized in step 8 and specified on the ROOT card. The following script is provided as an example where a root card exists in the configuration deck and a part card does not exist. Parameters of cards will vary according to the configuration of individual sites. User input is preceeded by an exclamation mark (!). bce (boot): M-> ! config M-> ! /root/ root -subsys dski -drive 1 M-> ! s/$/ -subsys dski -drive 2/p root -subsys dski -drive 1 -subsys dski -drive 2 M-> ! /part/ Search failed. M-> ! a M-> ! part bos dski 1 M-> ! part log dski 1 M-> ! part dump dski 1 M-> ! \f M-> ! w M-> ! q bce (boot) 1215.2: M-> reinit _S_T_E_P _7_: _R_E_L_O_A_D _O_F _E_X_E_C_U_T_A_B_L_E _L_I_B_R_A_R_I_E_S Do a normal boot "BOOT". While at ring-1 initializer command level load the executable libraries. This is done as follows: bce (boot): ! boot Command: M-> ! reload -nosetlvid Only the system libraries (MR11.EXEC) should be reloaded at this time. The -nosetlvid control argument ignores the logical volume ID on the tape when a directory is being reloaded. M-> ! shut 1230.1 shutdown complete. bce (boot) 1231.1: M-> ! boot standard (ignore the messages from sc_init_.) Multics MR11.0 - 04/29/85 1235.2 mst Mon Ready M-> ! admin admin: Entry not found. Could not retrieve admin password from the PNT to check admin password. Entering admin mode. Instructions - First Time 5-8 SIB11.0 [NOTE: This error message is repeated each time admin is entered until a password has been set.] Register and initialize all non-RLV volumes. Use the add_vol_registration (avr) command as in the following example: ! avr -pv pub01 -lv public -serial 233-81 -model 451 add_volume_registration: LV "public" does not exist. Do you wish to create it? M-> ! yes add_volume_registration: Registered PV "pub01" (pvid 100172223140) on new LV "public" lvid 100172223005). r 12:45 1.473 8 To create registration entries for each logical and physical volume. The registration file for the root logical volume is created automatically by the bootload. Since the default model number is 451, use the change_vol_registration command, if necessary, to set the correct value of model number on the rpv. The serial number can also be set as follows: lvr -pv rpv cvr -pv rpv -serial 233-79 -model ame Use the init_vol for the additional logical volumes as follows: init_vol pub01 dska_03 -special part alt high 141 end init_vol pub02 dska_04 -special part alt high 141 end After all physical volumes are registered and initialized, add them to the disk_table by typing the add_vol (av) command for all except the RPV: av pvname dskX_NN An example: av pub01 dska_03 At this point add all of the logical volumes by typing: alv -all Instructions - First Time 5-9 SIB11.0 _S_T_E_P _8_: _S_E_T_T_I_N_G _A_N_D _C_H_E_C_K_I_N_G _A_C_C_E_S_S The ACL for >lv should be set to "s" for all users. Setting initial ACLs for segments in the >lv directory is done from admin mode by typing: M-> ! admin M-> ! sis >lv rew *.SysAdmin rew *.SysDaemon M-> ! sa >lv s * sma *.SysAdmin sma *.SysMaint Create Access Control Segments (ACS) for each logical volume. For system public volumes, create them as follows: M-> ! create >lv>{lvname}.acs M-> ! cvr -lv {lvname} -acs >lv>{lvname}.acs set the max length to 0 for acs segment. where {lvname} stands for name of each logical volume. The ACLs of these segments are interpreted to give permission to attach the logical volume (for private volumes) and permission to modify master directory control information in the MDCS (for specific logical volumes). Specific ACL entries for Initializer.SysDaemon should be deleted at this time by typing: delete_acl >lv>*.acs This is necessary because Initializer.SysDaemon always gets default access of "rw". This would prevent the Initializer from being a volume administrator by virtue of the missing "e" access. Deletion of specific access gives the Initializer the "rew" access allowed all SysDaemons. The ACL is now set so that all system administrators and all SysDaemons are volume administrators. The "e" bit controls executive access. For private volumes, the ACS is in a directory controlled by the volume owner. The ACS segment must reside in a directory on a logical volume different from the private logical volume. _S_T_E_P _9_: _S_E_T_T_I_N_G _V_O_L_U_M_E _Q_U_O_T_A Use the set_volume_quota command to give the Initializer process enough quota on each logical volume to create the necessary master directories. Instructions - First Time 5-10 SIB11.0 set_volume_quota LV_NAME QUOTA Example: set_volume_quota public 36000 The number QUOTA should be at least the total of the quotas of the directories to be created in the next step. Use create_dir to create master directories. The format of the command is: create_dir pathname -lv logical_volume -quota QQ where QQ <262144 Example: cd >library_dir_dir -lv no_backup -quota 40000 cd >library_dir_dir>include -lv public -quota 3000 The acct_start_up.ec will, in step 11, create a number of project directories and assign terminal quota if the directories do not exist. They are the following with the quota that will be assigned: >udd>SysAdmin 5000 >udd>SysAdmin>admin 2000 >udd>SysDaemon 5000 >udd>Daemon 1000 >udd>Operator 100 >udd>Terminals 10 >udd>HFED 5000 Set ACLs and additional names, as desired, on all master directories at this time. Directory quota should be set for each master directory by those sites that wish to have disk charges for directory pages included in monthly bills. Those sites not interested in implementing this feature may type "ame" and "shutdown" then skip to the next step. A directory quota of 1000 pages should be sufficient for all master directories with the exception of >udd. If udd is a master directory it is recommended that it be given a directory quota of 100000 pages. This provides enough directory quota for 100 projects at 1000 pages each. If the site has more than 100 active projects the 100000 figure should be adjusted accordingly. To set directory quota on each master directory execute the following command: set_dir_quota PATHNAME QQ Thic command allows a system administrator to place an arbitrary secondary storage quota for directories on a specified directory. Instructions - First Time 5-11 SIB11.0 PATHNAME is the name of a directory on which the directory quota is to be placed. -wd can be used to specify the working directory. QQ is the directory quota in 1024 word pages. If additional directory quota is required for a master directory the quota can be reset following movement of directory quota to inferior directories. Instructions for moving directory quota down to the project level is included in Step 17. To shut down do the following: ame shut _S_T_E_P _1_0_: _R_E_L_O_A_D _O_F _R_E_M_A_I_N_I_N_G _R_E_L_E_A_S_E _T_A_P_E_S Reboot Multics to ring-1 and reload the MR11.LDD_STANDARD, MR11.UNBUNDLED and optional MR11.LISTING tapes with the following commands: boot alv -all reload -nosetlvid The tape labeled MR11.MISC must be the final tape of the MR11 supplied set to be reloaded. _S_T_E_P _1_1_: _R_U_N_N_I_N_G _A_C_C_T___S_T_A_R_T___U_P_._E_C After all the release tapes have been reloaded cross into ring-4 by executing the following commands: standard admin [Ignore messages from admin at this time.] Instructions - First Time 5-12 SIB11.0 While in the admin mode, check the acls, add names and ring bracket's on the following libraries, make sure that the ring bracket's are 7 7. If it is necessary to correct any of the ring brackets on directories use the lsdrb command. >library_dir_dir >library_dir_dir>system_library_unbundled >library_dir_dir>include >system_library_unbundled >documentation >documentation>subsystem At this time you are ready to execute part 1 of the acct_start_up.ec. To do this type: ec >system_library_tools>acct_start_up cold F.ANSS where F.ANSS is the channel number of the hardwired Initializer terminal. F = FNP number (a-h) A = Adaptor type (h = hsla) N = Adaptor number (0-2 for hsla) SS = Decimal subchannel number of specified adaptor The string "F.ANSS" should be replaced by "otw_" if there is no hardwired terminal and the bootload console is to be used as the Initializer terminal. At this point, tapes dumped from other Multics sites can be reloaded as desired using the "reload" command with the control arguments "-noquota -notrim -nosetlvid" to avoid deletion of existing segments and resetting of quotas. If any segments are to be loaded into ring 1 then it cannot be done without exiting admin mode and rebooting to ring 1. _S_T_E_P _1_2_: _M_U_L_T_I_C_S _C_O_M_M_U_N_I_C_A_T_I_O_N_S _S_Y_S_T_E_M A Multics Communications System (CS) core image is supplied in the >unbundled library, and is named site_mcs. The site_mcs version for this release is 7.3. The site_mcs core image contains the basic support for DN6780 type FNPs with 64k of memory. The communication system core images are built using the bind_fnp command in conjunction with a bindfile describing the CS modules and configurations to be used. A copy of the site_mcs.bind_fnp can be found in >ldd>mcs>info. Instructions - First Time 5-13 SIB11.0 Sites should build their own CS core image tailored to their own FNP configuration, terminal type requirements, and use of additional separately priced FNP software modules. Sites using the default site_mcs core image should ensure the CMF image statement points to the correct default core image located in >unb. The initial CMF, which includes some sample channel entries in comments, as well as one FNP entry, should be checked. Edit this CMF to eliminate any inconsistencies with the actual configuration and add one or more entries for login channels. Sites modifying their own CS core image are required to use the GCOS Environment Simulator which is an unbundled software product. To build a new core image, the following procedure is suggested: Sites will need to extract the communications object segments from archives located in >ldd>mcs>object. Sites should create a virgin directory under >udd>sa>a for each new core image. The following example is for sites with the more common type Datanet and a larger memory configuration. Execute the following commands: create_dir >udd>sa>a>mcs.7.3 cwd >udd>sa>a>mcs.7.3 qx r >ldd>mcs>info>site_mcs.bind_fnp (or location of sites CS bind file) . . . make editing changes if any.. . . . w site_mcs.bind_fnp q ac x ([segs >ldd>mcs>o>*.archive -absp]) bind_fnp site_mcs -list Instructions - First Time 5-14 SIB11.0 Be sure the image statement in the CMF points to this newly created CS core image. The following example assumes the default CMF to be in the >udd>sa>a directory. This procedure will insure that the new CS image is used: cwd >udd>sa>a qx r CMF.cmf . . Edit the image: statement to point to the CS image. Make any other changes needed. . . w CMF.cmf q cv_cmf CMF.cmf copy CMF.cdt >sc1>cdt -force The above procedure builds a site dependent CS core image and ensures that this image is loaded in the FNP by the answering service. _S_T_E_P-_1_3 During this step, expect many messages, some with audible alarms, reporting that certain segments do not exist and are being created. These messages would be cause for concern during normal system operation but are to be expected during accounting start up and may be ignored. Execute the following example: ame stop_mpx a (sites with multiple FNPs execute this command for each FNP) multics load_mpx a -check (sites with multiple FNPs execute this command for each FNP) admin (any error messages displayed at this time, except hardware error messages can be ignored.) ec >tools>acct_start_up cold2 This procedure will finish accounting start up. The load_mpx command indicates on the FNP console any configuration errors if console_man is loaded and "console: yes;" is in the bind_file. If any errors are reported they should be corrected. A default start_up.ec is available for use by new Multics users when they first log in. This exec_com is executed by users who login to the system without their own start_up.ec. The segment >tools>start_up.ec was copied into >sc1 by the acct_start_up.ec. Individual sites can modify this exec_com to meet their own Instructions - First Time 5-15 SIB11.0 needs. The access for the segment should be "r *.*.*" and ring brackets of 4,5,5. To start the system up for normal service type: ame word login abs start go After typing "go" a number of messages will be returned. These messages are of the form: absentee_utility_: Entry not found. Creating new . These messages may be ignored. _S_T_E_P-_1_4 Type "admin" and enter the new admin password you selected. Check the ACLs for >sss>dm_admin_gate_, >sss>dm_daemon_gate_, >tools>installation_tools_, >tools>pnt_admin_gate_, >tools>pnt_network_gate_, >sss>metering_gate_ and >sss>queue_admin_. The ACLs on these gates are as they appear on System M and should be restricted. The ACL for these gates are site dependent and should be changed to meet each site's needs. The dm_admin_gate_ and dm_daemon_gate_ should be restricted to data management administrators or daemons. The installations_tools_ gate should be restricted to system library maintainers. The pnt_admin_gate_ and pnt_network_gate_ should be restricted to system administrators. All persons on the ACL for metering_gate_ have access to the Multics metering data. All persons on the ACL for queue_admin_ are permitted to move absentee and daemon requests for themselves and other users to different queues. Users not on this ACL are only able to move their own requests. The Initializer must have access to queue_admin_. This capability is also dependent on extended access to the .ms segments. Set ACLs on the >sc1>rcp directory and on the access control segments in it (.acs), to allow users to attach tape drives and any other peripherals they are allowed to use. After all ACLs are set, type: ame x repair salvquota > 2 -dcf -rebuild _S_T_E_P-_1_5 Type "logout * *" and "shutdown". After a successful shutdown, do a SAVE. Use fresh tapes for the SAVE so that the results of the above steps are not lost. Instructions - First Time 5-16 SIB11.0 _S_T_E_P-_1_6 The system is now ready for registration of projects and users. The acct_start_up exec_com creates default system_start_up.ec, admin.ec, iod_tables.iodt, and CMF.cmf segments. These segments should be tailored by the local Site SA to meet site operational and configuration requirements. _S_T_E_P-_1_7 The following instructions are necessary only for those sites that intend to use the Volume Backup/Reloader facility: The personids "Volume_Dumper", "Volume_Reloader", and "Volume_Retriever" are registered. These personids are registered on the Daemon project with the multip and daemon attributes and with a home_dir of >user_dir_dir>Daemon>Volume_Dumper. Sites using AIM must set the authorization for these personids at system_high and upgrade the home_dir at system_high. Login Repair SysDaemon, or if running in special session using the Initializer, execute the following command: ec >tools>setup_volume_reloader This exec_com creates all directories, segments, and message segments necessary for running the volume dumper/reloader system. This exec_com also sets suggested access on the directories and segments created. Not all the access set is required. If a site wishes, the access created for *.SysMaint.* and *.SysAdmin.* may be removed. This exec_com resets the vtoce fields for both incremental and consolidated dumps by making a first dump pass with output to discard_. This is necessary since the first dump pass is equivalent to a complete dump on both the incremental and consolidated pass. Follow the instructions for normal use of this facility at the completion of this exec_com. Sites need a sufficient number of tapes to accommodate the entire file system and any incremental and consolidated dumps until a subsequent complete dump is taken. This is known as a reload group. It is suggested that new sites start with 100 reels of tape or a sufficient quantity to contain two complete reload groups. A single reel of tape at 6250 bpi holds approximately 26000 Multics records. _S_T_E_P-_1_8 Instructions - First Time 5-17 SIB11.0 This step is necessary only for those sites that wish to charge their user projects for disk storage used by directory pages, or to obtain a more complete disk report containing additional disk usage statistics. If directory quota is not already set on >udd execute the following commands from a SysAdmin process if udd is not a master directory: sac set_dir_quota > 120000 sac move_dir_quota >udd 100000 If udd is a master directory, then execute: set_dir_quota >udd 100000 Then execute the commands: cwd >udd move_dir_quota ([dirs **]) 1000 These commands move or set sufficient directory quota on udd for 100 projects with the suggested default project directory quota of 1000. If a site has more than 100 active projects a figure in excess of 100000 must be chosen for the initial directory quota of udd. The master.ec gives each new project a default directory quota of 1000 pages by moving 1000 pages of directory quota from udd. The system administrator should make sure there is always sufficient directory quota on udd to accommodate new projects. It is also suggested that all directories directly off the root with the exception of pdd and sl1 be given nonzero segment and directory quotas large enough to accommodate their current page usage and allowing for some growth. The purpose of this is to cause the disk report to contain complete statistical information on these directories (directories with 0 quotas are omitted from the disk report). MR10.1 to MR11 Migration 5-18 SIB11.0 SECTION 6 INSTRUCTIONS FOR SITES UPDATING TO MR11 FROM MR10.1 If problems are encountered in any of the Steps listed below, return to the last step known to be successful and retry the Steps. Pay particular attention to procedure. This entire procedure was verified on the Multics System at Phoenix Computer Operations, but some hardware/software differences may exist at a particular site. In this section, two formats of text are used to indicate the typing of input into the system. This input usually is a command line, but could be data typed in response to a query from the operator console. Strings of input, and output messages of importance are indicated on separate lines. In addition, all input to the system is to be typed in lowercase, except when indicated by the occurrence of both uppercase and lowercase in the input line. User input is preceeded by an exclamation mark (!). System display output is shown as is, except when the displayed line exceeds the page margins for this document. When this occurs, the displayed line is split into two lines, with the second line indented from the first. The procedure described in this section is intended for use by sites currently running the MR10.1 release. Sites running MR10.2 should follow the procedures found in "Section 4". Sites using NSA IOM's with NSDIA boards must insure option WIOG008A-001 is installed to make paged mode I/O work. MR10.1 to MR11 Migration 6-1 SIB11.0 _S_I_G_N_I_F_I_C_A_N_T _C_H_A_N_G_E_S _I_N _T_H_I_S _R_E_L_E_A_S_E 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. 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 like printer support, are not yet available within BCE. For this reason sites who require this continued level of support are advised to boot the system with the BOS tape provided with the MR11 package. It will then be possible to pass from BOS to the BCE command level or back to BOS from BCE directly. Sites who wish to take full advantage of BCE, and who do not normally require the need of the few special functions can boot directly from the MR11 Multics System Tape (MST) for normal operation. The installations instructions for this release will assume that BOS is being used. The operation of Bootload Multics is described in detail in Section 5.5 of the Multics System Maintenance Procedures Manual, Order number AM81-03. 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. With MR11, executing switches to force a manual return to Bootload Command Environment 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. With this release the toehold address to crash Multics has changed. The DMP's BOS command is no longer used. Instead, with FCO PHAOPD363 the DMP will except the BCE command with the octal switch value as the first argument. The argument normally will equal the address of the XED RTB instruction, For example, "BCE 24000" entered on the DMP will return the system to BCE level. For sites that need to revert to a previous release, "BCE 10000" Will cause a return to BOS. MR10.1 to MR11 Migration 6-2 SIB11.0 For a better discussion of the changes involved with Bootload Multics, refer to "Appendix A" of this document. With this release the processors (CPUs) will loop and appear to be hung rather than stopping on a DIS instruction as previously had been the case when an error was detected that couldn't be reported. With this release of firmware the idle pattern in the maintenance panel of the MTP610 or MTP611 will flash at a much faster rate. Expect this as normal. MR10.1 to MR11 Migration 6-3 SIB11.0 _S_T_E_P _1_: _P_R_E_-_I_N_S_T_A_L_L_A_T_I_O_N _P_R_E_P_A_R_A_T_I_O_N The following step can be executed any time prior to the shut down for installation of MR11. This step will create directories and segments used only in MR11. The examples given when setting access to segments and directories will provide the smallest working set and most restrictive. Each site should review the access it wishes to grant. The process that runs the crank, for example should be given correct initial acls to access the system logs. This step may be completed from a terminal where the user is registered with the SysAdmin project or has logged in as Repair.SysDaemon. It is recommended that system personnel examine the new system exec_coms and select files provided with MR11. This can be done prior to starting the installation by doing a cross-retrieve. The system exec_coms can be found on the 11.EXEC tape. A Sample Retrieval: >tools>master.ec=>udd>SiteSA>11.release>11.master.ec The site should review the system_start_up.ec, biller.ec, util.ec, utility_start_up.ec, admin.ec and master.ec to merge any local site changes in with the supplied exec_coms. The system exec_coms have been extensively rewritten. New default report control files are provided to replace log_select_files and syserr_select_file. the files daily_io_log.ssl, daily_admin_log.ssl, daily_syserr_log.ssl and daily_as_log.ssl in >tools should be reviewed and merged with any local site modifications. The perm_syserr_log vfile will no longer be used. All syserr messages have been moved into a new syserr log directory. The directory must be created on the RLV, with correct AIM level and sufficent quota. With this release the access to the syserr log is controlled differently than before. The new syserr log consists of 2 segments in >system_library_1, and one or more segments in >system_control_1>syserr_log. By default, the ACL on the segments in >system_library_1 is "r" for the SysDaemon, SysAdmin and SysMaint projects, "rw" for the Initializer and "null" for all other users; this ACL is provided by the hardcore.header. The ACL of >system_control_1>syserr_log must be "s" for anyone allowed to read the log. The Initializer and any process allowed to trim the log must be given "sma" access. The IACL must be "rw" for the Initializer.SysDaemon and "r" for any user allowed to read the log. There is no longer an audit_gate_ to control MR10.1 to MR11 Migration 6-4 SIB11.0 access. A quota should be placed on >system_control_1>syserr_log to limit the effect of run away syserr messages. When quota is exceeded, an Answering service dump is generated and copying will stop. To prepare the new log do the following: create_dir >system_control_1>syserr_log -quota Q Where Q is sufficent quota to hold a reasonable number of log segments. It is recommended that the initial quota be set at 15000 which will hold approximately ten (10) days of syserr logs. For this installation an new PNT and MAIL_TABLE will be created. Before starting the installation ensure that there is sufficent quota to hold the existing segments located in >system_control_1 and >site, and the new segments allowing a growth factor of 25%. With MR11, all system access control segments will be centralized into one admin_acs directory. Create the directory and set the approperate access according to your system needs. To move the existing system ACS segments to the new directory execute the following: cwd >sc1 rename proxy admin_acs add_name admin_acs proxy set_acl admin_acs sma *.SysAdmin sma *.SysDaemon null * -replace set_iacl_seg admin_acs rw *.SysAdmin rw *.SysDaemon null * -replace copy >system_control_1>**.install.acs >system_control_1>admin_acs>== -all copy >system_control_1>rcp>tandd.acs >system_control_1>admin_acs>== -all The send_admin_command (sac) has been reimplemented. The control segment >system_control_1>communications has been deleted. Access to use this command will be controlled by the new ACS segment >system_control_1>admin_acs>send_admin_command.acs. Execute the following commands to prepare the "sac" command for proper access: cr >system_control_1>admin_acs>send_admin_command.acs copy_acl >system_control_1>communications >system_control_1>admin_acs>send_admin_command.acs For MR11 a new ACS segment will be used for Data_Management Daemons. If the site intends to use Data Management, then a bump_user.acs and a process_termination_monitor.acs segment must be created. To create these segments type: cr >system_control_1>admin_acs>bump_user.acs cr MR10.1 to MR11 Migration 6-5 SIB11.0 >system_control_1>admin_acs>process_termination_monitor.acs These segments should only have access for Data_Management daemons and administrators. See the Data Management Appendix, Appendix C, for more detail. With this release the access to Hexadecmal floating point operations will be controlled with a new ACS segment. If the site intends to use this feature, then a Fortran_hfp.acs segment should be created. See the Fortran Users Guide for more detail. All logs produced by the answering service and message coordinator are now standard system logs. The pathname for log, iolog, vinc_log, vret_log, imft_log and admin_log is >system_control_1>as_logs. Any site defined Daemons that log into this directory should be checked. To allow continued logging, created the directory as follows: cd >system_control_1>as_logs set_iacl_seg as_logs rw *.SysAdmin rw *.SysDaemon null * With this release analyze_multics supports the analysis of dead processes. A new tool, copy_deadproc, copies saved dead process directories into a directory >dumps>save_pdirs. The site should create the master directory, from a process with appropriate access and privilege to set mdir quota, as follows: create_dir >dumps>save_pdirs -lv VOL_NAME -quota Q Where Q is sufficent quota to hold a reasonable number of process directories for site investigation. It is recommended that Q be initially set to 10000 records. cwd >dumps>save_pdirs set_acl -wd sma *.SysAdmin sma *.SysDaemon s * set_iacl_dir -wd sma *.SysAdmin sma *.SysDaemon null * Before starting, examine all pmf's for users permitted to login above system_low, they must be changed to include explicit "Authorization" or "authorization" statements. For example: authorization: "system_high"; The system is now prepared for the update of MR11. Continue to the next step. _S_T_E_P _2_: _I_N_S_T_A_L_L_A_T_I_O_N _I_N_S_T_R_U_C_T_I_O_N_S Due to the extensive changes to the answering service and administrative databases it is recommended that the site complete_dump, or copy to another safe directory structure, the directories >system_control_1, >site>mail_system_dir, >udd>sa>lib MR10.1 to MR11 Migration 6-6 SIB11.0 and >udd>sa>a. In the event the installation must be aborted or backed out, a retrieve of these directories and a reload of the executable libraries (i.e.,not system MR11) will allow continued operation with the old release. The directories dumped and the executable libraries can be reloaded with the old systems MST tape at ring 1 with the reload_system_release command. Using the 10.1 BOS System, perform a SAVE. A double save is recommended to avoid any possible tape problems later. With this release two new partitions are required on the rpv for BCE operation. These are the "bce" partition of length 2200 records and the "file" partition of length 255 records. These may be created by use of automatic or manual partition creation. The ability to run without a log partition is removed with this release. Additionally, the LOG partition must be on the RPV. If your LOG is not now on the RPV volume then it must be included when rebuilding. The standard size of the LOG partition is 255 records. Sites that require auditing should consider a larger size LOG partition within the 513 record limit. _A_u_t_o_m_a_t_i_c _P_a_r_t_i_t_i_o_n _C_r_e_a_t_i_o_n A first boot of MR11 is capable of creating the required BCE partitions. To allow this to work, at least 3000 records (2455 for the new partitions and around 500 for rpv only segments created during later initialization) must be free on the rpv. Using the 10.1 operating system to determine if enough free space exists type: list_vols -pv rpv the second number appearing after the drive name is the records available on rpv. If this number is greater than 3000, MR11 may simply be booted at this time. The required partitions will be created at the high end of the disk, just below any partitions currently at the high end. This generation takes on the order of 10 minutes during this first boot. If there are not enough free records on the rpv, some segments will have to be moved to other drives. Use the sweep_pv command to move small collections of segments to other physical volumes in the RLV until enough free space exists. _M_a_n_u_a_l _P_a_r_t_i_t_i_o_n _C_r_e_a_t_i_o_n The required partitions may also be created manually, using rebuild_disk performed with the 10.1 system. Before starting the rebuild_disk of the rpv, it will be necessary MR10.1 to MR11 Migration 6-7 SIB11.0 to add to the config deck's parm card: PARM DIRW Sites that don't normally run with the "dirw" parameter should remove this from the config after the rebuild_disk is complete. Assume that the rpv is mounted on dska_01 and a scratch pack is mounted on dska_02. Boot, using the 10.1 Multics System Tape (MST), not the MR11 MST, to ring-1 command level by executing the following: boot N (where N is the drive number of the 10.1 MST) rebuild_disk rpv dska_01 -copy dska_02 The rebuild_disk command will report information about the size of the partitions found on the source rpv. This information should be noted for use when constructing the new partitions on the target rpv. The rebuild_disk command will prompt for input, at this point the new partition layout should be entered as in the example that follows: request: part alt high 141 (on MSU451/400 only) request: part bos high 270 request: part log high 256 request: part dump high 2000 request: part file high 255 request: part bce high 2200 request: part hc low 2500 request: part conf low 4 request: nvtoce request: list request: end When the rebuild_disk is complete, shutdown and boot with the new rpv located on dska_02. For sites with MSU500 type units, the BOS SAVE COPY command can be used to move the temporary RPV back to the original device. _S_T_E_P _3_: _P_R_E_P_A_R_A_T_I_O_N _F_O_R _M_R_1_1 _I_N_S_T_A_L_L_A_T_I_O_N It will not be possible to boot with the old release after this step is complete. The site should run the crank one last time to clean up as much of the system before shut down. Be sure the Root volumes contain enough space for growth. See "Automatic Partition Creation" under "Step 2". A save of the systems administrative directories should be done as outlined in step 2. MR10.1 to MR11 Migration 6-8 SIB11.0 We are now ready to shutdown and re-boot for the last time on the 10.1 release. To do this go through the procedure established at your site for normal shutdown. Boot using the Multics System Tape (MST) for MR10.1 to Initializer ring-1 command level and type: boot N (where N is the drive number of the 10.1 MST) alv -all standard admin The following will prepare the system for conversions which will follow: set_acl >lv sma *.SysAdmin sma *.SysDaemon create_dir >lv.mr10 set_acl >lv.mr10 sma *.SysAdmin sma *.SysDaemon To exit admin mode and continue on to the next step type: ame mult (starts answering service) go (in special session.) For MR11 a new volume registration database will be created. User access to a private logical volume will be computed using the ACS pathname contained in the volume registration database. The links that existed in past releases under the directory >lv will no longer be used, the control segments will be moved into the directory. The following sequence will need to be executed from a privileged process in Ring 1. We recommend using Ring_1_Repair.SysDaemon and execute the following instructions: cwd >lv unlink lv.root unlink lvid.!* unlink pv.** unlink pvid.!* unlink root.mdcs Save the MR10 versions of the registration information. copy lv.** >lv.mr10>== -nm Move the master directory data into >lv. copy lv list **.acs -all -sort print_config_deck Due to the method by which unbundled software is dumped, normal trimming during reloading of new software does not occur. To ensure that unbundled directories are clean execute the following: cwd >system_library_unbundled answer yes -bf hpdl ([files **]) cwd >library_dir_dir>unbundled>source answer yes -bf hpdl ([files **]) cwd >library_dir_dir>unbundled>object answer yes -bf hpdl ([files **]) To shut the system down and continue to the next step type: ame shutdown _S_T_E_P _4_: _I_N_S_T_A_L_L_A_T_I_O_N _O_F _B_C_E This step involves booting BCE for the first time. If the partitions were not created manually as described in Step 2 they will be created automatically during this step. These partitions are required for BCE. A complete description of the procedure for booting BCE can be found in the Multics System Maintenance Procedures Manual, Order number AM81. A sample dialog with user input preceded by an exclamation point (!) follows: Place the MR11 BOS TAPE on any convenient drive, set the MPC switches to reflect this tape drive, and initiate the MR10.1 to MR11 Migration 6-10 SIB11.0 INITIALIZE/BOOT sequence of the IOM. The system will then proceed in the manner shown below. Start by loading all the controllers on the system with the new firmware. Do this for each controller you have configured: ENTER TAPE CONTROLLER TYPE: FWLOAD-> ! t601 BOOTING T601 on IOM A CHN 21 BOOTED t601 WITH M601 REV.N1 FIRMWARE. FWLOAD-> ! d451 a 22. BOOTING D451 on IOM A CHN 26 BOOTED D451 WITH M191 REV.P1 FIRMWARE. Proceed by loading out the MR11 BOS into the BOS partition: FWLOAD-> ! cold 451. 22. 1 BOS PARTITION AT 37847. FOR 270. BOS MR11 at 18:19:17 EST WED 7/18/84 BOS-> ! config l {conf1} Place the new MR11 MULT tape on any convenient tape drive, for our example we will be using drive 2, and proceed into the new ring-0 environment: BOS-> ! boot 2 BOOTING TAPE MULT bootload_0: Booting system MR11 generated 11/01/84 0000.0 1620.1 announce_chwm: 353. pages used of 512. in wired environment. 1620.2 announce_chwm: 626. words used of 1024. in int_unpaged_page_tables. 1620.4 init_root_vols: Adding bce file partitions to rpv. 1622.0 load_mst: 627. out of 1048. pages used in disk mst area. bce (boot) 1623.5: o.inl 0 At this time, bce has been booted. _S_T_E_P _5_: _C_H_A_N_G_E_S _T_O _C_O_N_F_I_G _D_E_C_K To change the config deck enter the config qedx editor by typing: config 1,$d a It is now necessary to to build a new MR11.0 configuration deck. Particular attention should be given the PRPH OPC, FNP, IOM, CPU, and PARM cards. This is done as follows: MR10.1 to MR11 Migration 6-11 SIB11.0 Changes have been made to the console software and firmware to support unechoed reads from the console. With this release it becomes possible for sites utilizing CSU6601 (LCC) consoles, with firmware revision C.0 installed, FCO PHAFKJ113, to enter the admin password on the console without having it echoed to the screen or any attached monitor. This option is controlled by the "MASK" keyword on the PRPH card describing each console. If C.0 firmware and FCO PHAFKJ113 have not been installed the site MUST use the "MASK" keyword. The next line shows proper syntax for the PRPH OPC card: PRPH OPC {MASK} NOTE: The MASK field dosn't apply for EMC style consoles. EMC consoles will always be set to mask the password regardless of the MASK field state on the card. The "FNP" config card is eliminated from the config deck. The fnp will be defined on the prph cards. Add the following prph card for each of the FNPs: PRPH FNP IOM CHANNEL MODEL STATE Where the FNP is a letter (A through H). The CHANNEL field must be valid and if decimal must be followed by a period (e.g., 13.). The MODEL field must be a valid model number followed by a period (e.g., 6670.). The 6670. model designation is valid for either the 355 or 6678 FNP type. The STATE field must be either on or off. An "ON" specifies that the FNP can be loaded by the answering service if the CMF calls for it to be loaded. An "OFF" state specifies that the FNP may not be loaded by the answering service even if the CMF calls for it to be loaded. One card should be inserted into the config deck for each FNP. With this release, all IOMs must be operated in paged mode. The operating mode switch on the IOM must be set to "PAGED" and the model field on all IOM cards must be "NSA". A new field is now provided on the PARM card to improve disk performance. The default value for the new parameter DSKQ is as follows: wlim for each 451 = 20 wlim for each 501 = 80 If WLIM has been used at the site, then set DSKQ to 150% of the WLIM value, if it is more then the total of the default value. The WLIM parameter on the PARM card is no longer honored and may be removed. The new tune_disk command functionally replaces this parameter. The ASTK parameter on the PARM card is no longer honored and may MR10.1 to MR11 Migration 6-12 SIB11.0 be removed. Generation of sst_names_ will now be generated in the bce_dump program. IOM switches can optionally be validated for consistency when the device is added to the system by adding the RICS parameter to the PARM card in the config deck. Sites using "PARM DIRW" in the configuration should remove this parameter during the tape loading phase. This significantly speeds up the reloading of tapes. This parameter should be inserted again when the system is rebooted. All root logical volume, physical volumes should be listed on the root card. The exception will be to rebuild a root volume with rebuild_disk or reload a volume with volume reloader. The following describe the new card formats used in the config deck for MR10.2. A complete write up of the changes made to the following configuration cards can be found in the MR10.2 version of the Multics Operator's Handbook, AM81. o The MR10.2 release changed the CPU card to identify the cache size of the processor. Changes to the CPU card are as follows: CPU tag port state {type} {model} {cache size} {expander port} where the new field: cache size: is the cache size of the processor expressed in Kilo-words (1kw = 1024 words). Example: CPU A 7 ON DPS8 70. 8. o A new operator console support package was included in MR10.2. It offers the advantage of dynamic console recovery in console failure situations. In addition to the changes made for MR11, MR10.2 required the site to replace the PRPH OPC card with the following: PRPH OPC IOM CHNL MODEL LINE_LENG STATE where: is a letter (A through H). One card should be inserted into the config deck for each configured console. LINE_LENG: Indicates the number of columes per line of the console. STATE: Indicates the condition of the console as follows. MR10.1 to MR11 Migration 6-13 SIB11.0 ON - Specifies that the console is selected as the bootload console and is the primary recipient of I/O. There must be one and only one console specified with a state of ON. ALT - Specifies that the console is to be utilized as an alternate console in the event of bootload console failure. If an alternate console is found its state is changed to ON and it becomes the bootload console. Alternate consoles are selected in the order that they appear in the config_deck. IO - Specifies that the console exists but is not usable as an alternate console. This allows the console to be attached by any qualified process as an I/O device. INOP - Specifies that the console is inoperative. This state is normally assigned dynamically during console recovery. EXAMPLE: PRPH OPCA A 14. 6601. 80. ON o A new field is provided on the PARM card that specifies the system to crash if the console recovery completely fails. If the site considers running without a console a security risk, then the CCRF field should be added to the PARM card. Otherwise the system will continue running without a console. PARM CCRF o With MR10.2 an optional PART card called CONF has been added. Existing sites do not need to do anything about this field as the system will extract 4 records out of the hardcore partition and create this automatically. This area of disk will contain the configuration deck for use by Multics in a future release. o The RVTC card is no longer used and should be removed. After having made necessary changes type: w q bce (boot) 0001.7: reinit The "w" request will verify card syntax. The "q" request will leave the qedx editor and place the user at the bce(boot) level. Typing "reinit" at bce(boot) forces changes to the config deck to be saved in the "conf" partition. MR10.1 to MR11 Migration 6-14 SIB11.0 _S_T_E_P _6_: _R_I_N_G_-_1 _E_N_V_I_R_O_N_M_E_N_T The system is now ready to cross into the ring-1 environment: bce (boot) 1200.5: boot Multics MR11 - 11/02/84 1201.0 est Fri. Command: Users should expect the console to report the following messages: init_syserr_log: Converting MR10.1 syserr partition init_syserr_log: Syserr LOG partition reinitialized volume_registration_mgr_$check volume_registration: Converted ">lv>lv.root to version 2. (Initializer.SysDaemon.z) The message will be given for each logical volume. At Initializer ring-1 command level, type: alv -all At this point the libraries will be reloaded. The release tapes should be reloaded in this specific sequence: EXEC, LDD_STANDARD, UNB, and MISC. To complete the library reload type: reload_system_release -nosetlvid When the system asks "Input tape label:" type: where is the reel identification specified for the next tape to be reloaded. See Section 2, "Contents of MR11 Package," for a listing of all "Tape names". Repeat this step for each library tape. When all tapes are loaded, type: standard admin The system will enter admin mode without the need of a password the first time it is used with MR11. The old password from communications is NOT automatically copied, you must set it after converting and setting access for the PNT. Sites should execute the following commands when entering admin mode in ring-4 for the first time under MR11. Sites that are currently using the forum product must initialize the forum notification data base to allow forum notification to work at all AIM levels. This is done by executing the following commands: MR10.1 to MR11 Migration 6-15 SIB11.0 ! cwd >site>forum_dir ! l_rename "Notifications Database" old.database ! set_system_priv dir seg ring1 ! forum_admin init_notifications ! cwd >sc1 Additional extended operator commands, as an extension of admin.ec, are available from a new exec_com called admin_1.ec. ! copy >t>admin_1.ec MR10.2 requires that the >site>mail_system_dir directory is created to allow Multics mail to work. In addition, sites must also create the new mail table by hand before starting the answering service. The >site>mail_system_dir must reside on the RLV and have an access class of system_low. In addition, it must have sufficient quota (terminal or non-terminal) to hold the mail table. The mail table will occupy approximately three (3) times as many records as the PNT for any given site. If >site does not exist, issue the following commands before those given above: ! create_dir >site ! set_acl >site sma *.SysAdmin sma *.SysMaint s * ! set_iacl_seg >site r * ! set_iacl_dir >site sma *.SysAdmin sma *.SysMaint s * If >site does exist but is not on the RLV, then use the create_dir command as follows: ! create_dir >site>mail_system_dir -lv root -quota N where N is sufficient quota to hold the mail table according to the guidelines provided above. If >site already exists on the RLV and has sufficient quota (terminal or non-terminal) to hold the mail table, execute the following: ! create_dir >site>mail_system_dir the following will complete the installation by all sites: ! add_name >site>mail_system_dir mail_system mlsys ! change_wdir >site>mail_system_dir ! set_acl -wd sma *.SysAdmin sma *.SysMaint s * ! set_iacl_seg -wd r * ! set_iacl_dir -wd sma *.SysAdmin sma *.SysMaint s * ! convert_MR10_2_pnt PNT ! create_mail_table Sites using the hierarchy backup should update the dump control files to include the >site directory, if it isn't being dumped MR10.1 to MR11 Migration 6-16 SIB11.0 already. For sites which had been using the mailbox link directory >udd>Daemon>mailboxes, the cv_links_to_mail_table tool is provided to merge the information in the links directory into the mail table. Sites can use the -no_query argument if they do not wish to answer the questions which arise due to conflicts between the mail table and the mailbox links directory at this time. To register the names of users on the links, issue one of the following two command lines: ! >obs>cv_links_to_mail_table or: ! >obs>cv_links_to_mail_table -no_query System Administrators may wish to canonicalize the mailboxes of some of their users, either because the users are not familiar enough with the system to do this themselves or because they are in a limited environment in which this is not possible. An exec_com is provided to make it easy to canonicalize all the mailboxes in a subtree. To do this, issue the command line: ! ec >t>canonicalize_mailbox PATH where PATH is the pathname of the top of the subtree whose mailboxes are to be canonicalized. This exec_com assumes that the process has access to the gate system_privilege_ (for sites running in an AIM environment), and that it has "sma" access to the directories in the subtree; use of a SysDaemon process is therefore recommended. System Administrators planning to use this procedure should read the Notes section of the canonicalize_mailbox command documentation in AG92 or the Notes section of the info segment. There may be side-effects which are undesirable. The primary purpose for canonicalizing save and log mailboxes that contain a large number of messages is to speed up string searches within these mailboxes. It is probably best left to the individual user to determine whether or not mailbox canonicalization is necessary for their own hierarchy. This command does use a large amount of CPU time and sites are cautioned against using it across large hierarchies such as at the >udd or >udd>project level. Sites not running Inter-Multics File Transfer Facility (IMFT) are done and may continue to Step 7. Sites that are currently running the MR10.1 version of the Inter-Multics File Transfer Facility (IMFT) will need to convert from version 2.0 (MR10.1 version) to version 3.0 (MR11.0 version). MR10.1 to MR11 Migration 6-17 SIB11.0 The following provides information about changes to the Inter-Multics File Transfer Facility (IMFT) that were made between MR10.1 to MR10.2. Sites who are currently using IMFT, should follow the following procedure after the system libraries have been reloaded, and before the I/O Coordinator is brought up for the first time on MR11. The process of converting a site from IMFT version 2.0 (provided in MR10.1) to version 3.0 (provided in MR11.0) consists of 3 stages: -- modification of the I/O Daemon tables -- renaming the IMFT request queues -- converting the ACLs on users' IMFT access control segments I. I/O DAEMON TABLES The following is a summary of the changes that must be made to the I/O daemon tables for conversion to IMFT Version 3.0. For a complete description of the I/O Daemon tables statements for IMFT, see the IMFT Manual, Order No. CY73. A. Request Type Names The names of all request types used for transferring files and subtrees to foreign systems must be prefaced by the string "To_", e.g., a request type named "System_X" must be changed to "To_System_X". This change must be made not only in the Request_type definition, but also in the "default_type" statements of all device definitions. If the site wishes to use the remote request feature, i.e., to permit use of the -source control argument to enter_imft_request, a request type must be created for each foreign system that can be a source. The name of this request type is the name of the foreign system prefaced by the string "From_", e.g., "From_System_X". B. Minor Device Definitions The device definition for each IMFT output driver must include either one or two minor_device statements: one for transferring files to the foreign system, and the other for requesting transfers from the foreign system. The "default_type" statements associated with these minor devices should specify request types of "To_" and "From_" respectively. Thus, if the device definition for an ouput driver in the MR10.1 I/O daemon tables includes the statement: default_type: System_X; MR10.1 to MR11 Migration 6-18 SIB11.0 it should be replaced by the following statements, which must come at the end of the device definition: minor_device: to; default_type: To_System_X; minor_device: from; default_type: From_System_X; (If System_X is not to be used as a source, the last two statements above can be omitted.) The "device" statement in the corresponding Request_type definition must refer to the minor device, e.g.: Request_type: To_System_X; device: Sys_x_ft_out.to; . . Request_type: From_System_X; device: Sys_x_ft_out.from; C. Accepting remote requests If the site intends to act as a source for transfers requested by another system, the keyword/value pair "allow_remote_request=yes" must be added to the args statement in the device definition for the input driver for that foreign system. Such requests will be restricted by default to files and subtrees whose ACLs contain an explicit term giving "r" or "s" access to the Person_id of the driver (e.g., "IMFT.*" or "IMFT.Project"). If the site wishes to avoid this restriction, the args statement for the input driver must include the keyword/value pair "explicit_access=no". An IMFT input driver, serving pull requests will need re access to >sss>queue_admin_. All IMFT drivers have the same group id (e.g., IMFT.* or IMFT.Project). D. Communication With Earlier Versions In order to effect file transfers between your site and a site that is still running MR10.1, the keyword/value pair "version=2.0" must be included in the args statements for both the input and output drivers for that system. E. Use of "indirect" Keyword The parameters of the args statement can be replaced by the string: indirect=PATHNAME; MR10.1 to MR11 Migration 6-19 SIB11.0 where PATHNAME is the pathname of a segment or archive component, whose contents are the keyword/value pairs that would otherwise appear in the args statement itself (without the surrounding quotes). The use of this keyword is recommended for two reasons: (1) the string in the args statement itself is truncated at 256 characters, whereas the contents of the segment or archive component is not truncated; and (2) the contents of the referenced segment or archive component can be modified by the use of an editor without recompiling the iod_tables, and such modifications take effect the next time the driver is initialized, whereas changes to the I/O Daemon tables themselves do not take effect until the next login of the I/O Coordinator. II. IMFT REQUEST QUEUES After making the modifications described above and recompiling the I/O Daemon tables, the names of the request queues must be changed to correspond to the new request type names. (The queues should be renamed rather than recreated in case they have any requests in them.) Thus, for each foreign system for which IMFT queues exist, execute the following command: rename NAME_(1 2 3).ms To_NAME_(1 2 3).ms where NAME is the name of the foreign system. Then execute the create_daemon_queues command in order to create the queues for any request types that have been added (such as the "From_NAME" request types discussed above). III. ACS CONVERSION The meaning of the ACL modes on the access control segment (ACS) used by IMFT to determine the foreign user's privileges has been changed incompatibly. A conversion program, and an exec_com to invoke it, have been provided in >unbundled. The following command line, executed by a process that has modify permission on all home directories, will convert all user's IMFT ACSs to have the correct meaning for IMFT Version 3.0: exec_com >obs>imft_acs >udd The command has been designed to keep records in a file as it goes along, so that if the execution of this exec_com is interrupted before it is finished, it can be reinvoked later without danger of undoing (or redoing) what it had already done. Once the conversion has been completed successfully, this file should be deleted by the following command: delete >system_control_1>imft_acs_list This completes the conversions sites on MR10.1 need to do. MR10.1 to MR11 Migration 6-20 SIB11.0 _S_t_e_p _7_: _C_o_n_v_e_r_t_i_n_g _S_y_s_t_e_m _L_o_g_s The following will move all syserr messages from the ring zero LOG partition and the >system_control_1>perm_syserr_log vfile into the new syserr log directory. convert_syserr_log >system_control_1>syserr_log In MR11, the answering service logs, message coordinator and syserr logs have been converted to a common format. New commands have been added to manipulate the logs. The convert_old_log command will change existing logs to the new format. If you want to save the information in the answering service log or message coordinator log, execute the following: answer yes -bf convert_old_log LOG_NAME Where LOG_NAME can be log, iolog and any other site-define message coordinator logs. If your history directory is not >udd>sa>a>history, you need to type: convert_old_log LOG_NAME -ohd HISTORY_DIR_PATH If you want to use a directory other then >udd>sa>a>history as the first place old logs are put, use the -nhd argument. You must include this change in the new master.ec if used. The following commands should be executed to re-structure the answering service tables. convert_MR10_2_sat sat convert_MR10_2_pdts pdt The PNT is now called PNT.pnt and is a Ring-1 database. Using the set_acl command set the access on the new PNT.pnt for only those users requiring access to the PNT. The minimum access for correct system operation is as follows is rw for Initializer.SysDaemon and *.SysAdmin and r access for *.SysDaemon, IMFT.*.z, and Card_Input.Daemon. In addition the site can add access for any site-defined daemons which handle remote-io, card-input, and IMFT if the names differ from the ones specified in the example. To set the password, execute the following: set_special_password operator_admin_mode Password Where XXX is the admin password of your choice. The password is not echoed and the user is not asked for password verification. If you do not wish a password, do the following: MR10.1 to MR11 Migration 6-21 SIB11.0 set_special_password operator_admin_mode -none Many new parameters are provided with this release. The ed_installation_parm command must be invoked at this time to reset the version number. Additional changes will avoid warning messages when operation continues. The segment >system_control_1>communications will no longer be used. The size of the process directory is now an installation parameter. The following values are recommended: ed_installation_parms c log_parameters 10 (set the syserr log copy interval) c default_pdir_seg_quota 1000 (size of seg quota limit) c default_pdir_dir_quota 1000 (size of dir limit) w q cwd >udd>sa>a convert_MR10_2_sat smf.cur.sat convert_MR10_2_reqfile reqfile convert_MR10_2_projfile projfile convert_MR10_2_pdts safe_pdts convert_MR10_2_urf URF convert_MR10_2_use_totals ([segs **.use_totals]) The administrive exec_coms have been converted to V2 exec_coms. The uses of the old value command have been converted to the new value_set and value_get commands. The convert_old_value_seg command is provided to recover the data in the existing value segment. To convert the old value segment, execute the following: convert_old_value_seg >udd>sa>lib>value_seg >udd>sa>lib>sys_admin.value link >udd>sa>lib>sys_admin.value A value used by the crank to determine the last time the logs were processed needs to be set. Execute the following command to pre-set the value. value_set -pn sys_admin last_log_time [clock calendar_clock] where [clock calendar_clock] is of the form: YYYY-MM-DD__HH:MM:SS:NNNNNN_gmt_Thu. where YYYY is the year, MM is the month, DD is the day, HH is the hour, MM is the minute, SS the second, NNNNNN is the micro second, gmt can be ANY time zone, and Thu can be any alpha day description. The system mail table will be converted due to a change in format MR10.1 to MR11 Migration 6-22 SIB11.0 with this release. Execute the following command: convert_MR10_2_mail_table >site>mail_system_dir>MAIL_TABLE The convert_MR10_2_mail_table does not copy ACLs. Setting of MAIL_TABLE access is described in Step 9. The format of the coordinator's working tables has been changed. To assure that the coordinator is operating correctly in MR11.0 it is necessary to delete the coordinator directory at this time. When the Coordinator is logged in and attempts to access information in this directory, the directory will be automatically regenerated. Execute the following command: dd >ddd>idd>coord_dir -force The following system exec_coms have been modified for this release. Sites should have reviewed the changes and merged local modifications in with the changes provided with this release. Sites not needing to make any futher modifications should execute the following commands. Sites with modifications to the default exec_coms should replace the pathname to the shipped source with a pathname to the sites modified exec_com. answer yes -bf cp >tools>system_start_up.ec >system_control_1>== -update answer yes -bf cp >tools>admin.ec >system_control_1>== -update answer yes -bf cp >tools>util.ec >udd>sa>lib>== -update answer yes -bf cp >tools>master.ec >udd>sa>lib>== -update answer yes -bf cp >tools>err.ec >udd>sa>lib>== -update answer yes -bf cp >tools>biller.ec >udd>sa>lib>== -update answer yes -bf cp >tools>utility_start_up.ec >udd>SysDaemon>Utility>start_up.ec -update Use of the -update control argument makes it necessary to have write access to the various exec_coms. New default report control files are provided to replace log_select_files and syserr_select_file. the files daily_io_log.ssl, daily_admin_log.ssl, daily_syserr_log.ssl and daily_as_log.ssl in >tools should have been reviewed and merged with any local site modifications. If the site will run with the default values, following should be executed: copy >tools>*.ssl >udd>sa>a>== _S_T_E_P _8_: _F_N_P _C_O_R_E _I_M_A_G_E_S _A_N_D _C_M_F _C_O_N_V_E_R_S_I_O_N Two Multics Communications System (CS) core images are supplied in the >unbundled library, and are named "mcs" and "site_mcs". The "mcs" core image contains the basic support for DN355 type MR10.1 to MR11 Migration 6-23 SIB11.0 FNPs. The "site_mcs" core image contains the basic support for DN6780 type FNPs with 64k of memory. CS core images are built using the bind_fnp command in conjunction with a bindfile describing the CS modules and configurations to be used. A copy of the site_mcs.bind_fnp can be found in >ldd>mcs>info. The mcs.bind_file can be found in >ldd>355>info. Sites should build their own CS core image tailored to their own FNP configuration, terminal type requirements, and use of additional separately priced FNP software modules. Sites using the default "mcs" or "site_mcs" core image should skip to Step 8 after ensuring the CMF image statement points to the core image now located in >unb. To build a new core image, the following procedure is suggested: Sites will need to extract the communications object segments from archives located in one of two directories depending on the type of Datanet to be loaded. Sites with DN355 Datanets (DN6632 or DN6651 models) with 32k of FNP memory will find the objdk segments in >ldd>355>object. DN6678 datanets with 64k or more of memory will find the object segments in >ldd>mcs>object. Sites should create a virgin directory under >udd>sa>a for each new core image. The following example is for sites with the more common type Datanet and a larger memory configuration. Execute the following commands: create_dir >udd>sa>a>mcs.7.3 cwd >udd>sa>a>mcs.7.3 qx r >ldd>mcs>info>site_mcs.bind_fnp (or location of sites CS bind file) . . . make editing changes if any.. . . . w site_mcs.bind_fnp q ac x >ldd>mcs>o>([segs >ldd>mcs>o>*.archive]) bind_fnp site_mcs -list Be sure the image statement in the CMF points to this newly created CS core image. The name of the CMF requires a suffix of "cmf". The following example assumes the CMF to be in the >udd>sa>a directory. This procedure will insure that the new CS image is used: MR10.1 to MR11 Migration 6-24 SIB11.0 cwd >udd>sa>a qx r CMF.cmf . . 1) Edit the image: statement to point to the new CS image. 2) Replace any use of the check_acs flag for a channel with the appropriate per-channel statement: check_acs: login,slave_dial,dial_server,priv_attach,dial_out; 3) Replace any "access_class: ACC;" statements with: access_class: "MIN_ACC:MAX_ACC"; The new format is a range. For dial_out and slave lines, the minimum authorization (MIN_ACC) must be equal to the maximum authorization (MAX_ACC) (i.e. access_class: "system_low:system_low";) 4) Make any other changes needed. . . w CMF.cmf q cv_cmf CMF copy CMF.cdt >system_control_1>cdt -force The above procedure builds a site dependent CS core image and ensures that this image is loaded in the FNP by the answering service. _S_T_E_P _9_: _T_T_F _C_O_N_V_E_R_S_I_O_N A new standard TTF has been provided containing additional terminal types. Sites using a modified site dependent TTF should merge these changes with their modified version, and convert the TTF to its binary version. The converted binary version must then be installed to take effect. The TTF.ttf segment in >tools contains some of the more common used terminals on Multics. Sites using the default TTF for this release must execute the following commands to perform this conversion: cwd >udd>sa>a rename TTF.ttf TTF.save cp >t>TTF.ttf cv_ttf TTF install TTF.ttt MR10.1 to MR11 Migration 6-25 SIB11.0 Exit admin mode by typing "ame". Then issue the commands: stop_mpx a (sites with multiple FNPs execute this command for each FNP) multics load_mpx a -check (sites with multiple FNPs execute this command for each FNP.) go The load_mpx command indicates on the FNP console any configuration errors if console_man is loaded and "console: yes;" is in the bind_file. If any errors are reported they should be corrected. Sites should assure the correct version number is reported the first time the FNP is booted. _S_T_E_P _9_: _A_C_L_S _A_N_D _R_I_N_G _B_R_A_C_K_E_T_S Setting of MAIL_TABLE access can be completed by do the following (user typed commands are preceeded by an exclamation mark (!): M-> ! login Retriever.SysDaemon cd1 --> M-> ! r cd1 cwd >site>mail_system_dir --> cd1 M-> ! r cd1 sa * rw * -replace -no_sysdaemon --> cd1 M-> ! r cd1 logout which will provide necessary access to use MAIL_TABLE. Check library access and correct any ACLs or ring brackets which are not appropriate. With this release access to the PNT is controlled with new gates, we recommend the following as the absolute minimum to allow correct system operation. >t>pnt_admin_gate_ re *.SysDaemon.* re *.SysAdmin.* >t>pnt_fs_gate_ re *.*.* >t>pnt_login_gate_ re Initializer.SysDaemon.* re *.SysAdmin.* MR10.1 to MR11 Migration 6-26 SIB11.0 >t>pnt_network_gate_ re Initializer.SysDaemon.* re IMFT.Daemon.* re Card_Input.Daemon.* re *.SysDaemon.* >t>pnt_priv_gate_ re Initializer.SysDaemon.* r *.SysDaemon.* re *.SysAdmin.* Check the ACLs for >sss>dm_admin_gate_, >sss>dm_daemon_gate_, >tools>installation_tools_, >tools>pnt_admin_gate_, >tools>pnt_network_gate_, >sss>metering_gate_ and >sss>queue_admin_. The ACLs on these gates are as they appear on System M and should be restricted. The ACL for these gates are site dependent and should be changed to meet each site's needs. The dm_admin_gate_ and dm_daemon_gate_ should be restricted to data management administrators or daemons. The installations_tools_ gate should be restricted to system library maintainers. The pnt_admin_gate_ and pnt_network_gate_ should be restricted to system administrators. All persons on the ACL for metering_gate_ have access to the Multics metering data. All persons on the ACL for queue_admin_ are permitted to move absentee and daemon requests for themselves and other users to different queues. Users not on this ACL are only able to move their own requests. The Initializer must have access to queue_admin_. This capability is also dependent on extended access to the .ms segments. _S_T_E_P _1_0_: _V_O_L_U_M_E _I_N_F_O_R_M_A_T_I_O_N _A_N_D _O_P_E_R_A_T_O_R _L_O_G_I_N From a privileged process check the volume registration for the volumes listed in STEP 3. Add ACS path names to the volume registration as necessary. lvr -lv LVNAME cvr -lv LVNAME -acs_path PATH>LVNAME.acs To prevent quota problems while adding new projects it is necessary to provide directory quota to >user_dir_dir (>udd). This is done by typing: sac move_dir_quota >udd 100000 A number of undocumented initializer commands have been removed or changed. The MR11 documentation is accurate. The "list_requests" initializer command will show the MR11 commands available. At the initializer console type: list_requests Operator login facilities have been added. Persons with the new MR10.1 to MR11 Migration 6-27 SIB11.0 "operator" attribute in the PNT may use the sign_on and sign_off initializer commands to log in on the bootload console and/or initializer terminal(s). An installation_parm, require_operator_login, is provided to require that the operator log in before being permitted to enter commands. The default is to set this parameter off. To sign on as an operator, you must have the "operator" flag turned on in your PNT entry. You can require operators to log in with the require_operator_login installation parameter. By default this parameter is off. to turn on the operator flag: new_user$cga USER_NAME flags operator To print logs, use the print_sys_log command: print_sys_log -syserr for the syserr log print_sys_log -as for the answering service log print_sys_log -admin for the admin log print_sys_log -mcl LOG_NAME for a message coordinator log named LOG_NAME i.e. print_sys_log -mcl iolog to print the default I/O log. To monitor logs, use the monitor_sys_log with same control arguments. To produce sorted reports in the style of the now obsolete daily_log_process command, use the summarize_sys_log command. To move log segments from one place to another whle preserving the records that link together sets of segments, use the move_log_segments command. If you move them with the standard move command you will destroy the record of previous log segments. If the site has ordered forum see Step 12 before normal service is started. At this point installation of MR11 is complete. Normal service can be now started. The format of the directory information for directory quota has changed. It is suggested that the following exec_com be run from a privileged process after service is continued. Directory quota's are not validated at this time, but will be implemented in a future release. following command line will correct the directory quota values. ec >t>fix_dir_quota_used > -bf MR10.1 to MR11 Migration 6-28 SIB11.0 _S_T_E_P _1_1_: _S_Y_S_T_E_M _C_L_E_A_N_U_P After the system has been operational for a reasonable period of time, the old segments no longer required can be cleaned up. dl >system_control_1>rcp>tandd.acs dl >system_control_1>sat.install.acs dl >system_control_1>mgt.install.acs dl >system_control_1>rtdt.install.acs dl >system_control_1>cdt.install.acs The old PNT and MAIL_TABLE can now be deleted: dl >system_control_1>PNT dl >site>mail_system_dir>MAIL_TABLE.!* Additional cleanup can be done once the system is up and a reasonable time period has passed: dl >system_control_1>perm_syserr_log dl >system_control_1>sc.message dl >system_control_1>communications dl >udd>sa>lib>log_select_file (unlink in >udd>sa>a) dl >udd>sa>lib>syserr_select_file dl >udd>sa>lib>value_seg dl >system_control_1>tape.message The old >lv.mr10 directory should be deleted in 2 steps, 1. ldl >lv.mr10>** 2. answer yes dd >lv.mr10 (in Initializer process) 3. ldl lv.root; ldl >root.mdcs (in Initializer process) 4. unlink >lv>**.acs _S_T_E_P _1_2_: _F_O_R_U_M _I_N_S_T_A_L_L_A_T_I_O_N This step is necessary only for those sites ordering the Forum Product. Check the ACLs for >unb>forum_admin_ and >unb>forum_data_ (if the site ordered the Forum product). All persons on the ACL for forum_admin_ are able to use the forum_admin command to tailor operation of the Forum facility and to manipulate meetings chaired by other users. Site persons wishing to change the global forum parameters with the forum_admin command, will also need write access to >unb>forum_data_. Forum meetings should be converted to Version 2 format at the site's convenience. One meeting, Meetings_Directory.control in >site>forum_dir must be converted before service is started to allow the forum announce_meeting command to function correctly. To convert this meeting enter admin mode and type: MR10.1 to MR11 Migration 6-29 SIB11.0 convert_forum >site>forum_dir>Meetings_Directory.control This command converts the Version 1 meeting to a Version 2 meeting named Meetings_Directory.forum. We recommend that each site convert all of its forum meetings to version 2. Because version 2 forum supports version 1 meetings, this conversion need not be done as soon as MR11 is installed. The site-wide conversion tools consist of the three exec_coms installed in >unbundled called forum_find_v1, convert_meetings, and update_links. Info segments for all three exec_coms are supplied. The forum_find_v1 exec_com is run first to produce two lists: a list of all version 1 meetings in a hierarchy, and a list of all directories containing links to version 1 meetings. Next, the convert_meetings exec_com is run to convert all of the meetings to version 2. Finally, the update_links exec_com is run to update user's links to Version 1 meetings so that meetings are not lost in the conversion process. Each of these will produce error files should any errors occur. Most errors are not serious and the conversion pass can continue. Errors may then be corrected and a second pass run. For example: 1. ear >unb>forum_find_v1 -limit 10000 -ag > (finds v1 meetings and links and creates files MEETINGS, LINKS, MEETING_ERRORS, LINK_ERRORS, ERRORS) Examine error files for serious errors. Most will be due to no access and should not be considered serious. 2. ec >unb>convert_meetings MEETINGS (converts all meetings listed in MEETINGS to V2. Creates file CONVERT_ERRORS.) 3. ec >unb>update_links LINKS (updates all links listed in LINKS. Creates file UPDATE_ERRORS) Examine all error files, make appropriate corrections and run a second complete pass by repeating 1, 2 and 3. Conversion of meetings to V2 can be done after MR11 is installed and is not necessary to run MR11. Conversion can be done while normal service is running, but we recommend it be done during an off shift. None of these exec_coms force access to user's hierarchies. We suggest running the exec_coms in a privileged process such as Repair.SysDaemon and notifying users through the message-of-the-day that they should either grant or deny this process access as they feel appropriate. MR10.1 to MR11 Migration 6-30 SIB11.0 APPENDIX A 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 The 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 Bootload Multics (BCE) A-1 SIB11.0 previous BOS method of operation. Note, 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. Bootload Multics (BCE) A-2 SIB11.0 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. 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 Bootload Multics (BCE) A-3 SIB11.0 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. 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). Bootload Multics (BCE) A-4 SIB11.0 _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 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 Bootload Multics (BCE) A-5 SIB11.0 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 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. The DMP's BOS command is no longer used. Instead, with a new firmware change the DMP will accept BCE command with the octal switch value for the first argument. For example, "BCE 024000717200" entered on the DMP will force the XED into the data switches and execute the return to BCE level. The system will warn the operator on boot if the data switches on any processor are not set to the above value. Bootload Multics (BCE) A-6 SIB11.0 _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. 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 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 Bootload Multics (BCE) A-7 SIB11.0 operation. Other responses are allowed; refer to the MOH for more details. Bootload Multics (BCE) A-8 SIB11.0 APPENDIX B MODULE CHANGES FOR MR11 This appendix provides information about changes to the Multics operating system on a segment basis. The following information applies to changes made to the system for the MR11 release only. This appendix is provided to help sites identify, to a segment level, changes they may have applied for emergency bug fixes or site dependent modifications to current system software. Information is catagorized as follows: new info segments (added to >doc>info) new segments deleted segments Module Changes for MR11 B-1 SIB11.0 _N_E_W _I_N_F_O _S_E_G_M_E_N_T_S _F_O_R _M_R_1_1 MCC.gi.info bj_mgr_call.info MSF.gi.info bj_mgr_call.open.info Multics_card_code.gi.info bj_mgr_call.opened.info PNT.gi.info bj_mgr_call.sdp.info Satellite_6M.errors.info bjmc.cl.info abbrev_.info bjmc.closed.info ac.info bjmc.cr.info acc.info bjmc.gdp.info accepting.info bjmc.info access_class.info bjmc.o.info access_requests.info bjmc.sdp.info accounting.day.info bjmt.info active_fnc_err_.info bjst.info add_anon.info booktitle.compin.info add_char_offset_.info bootload_fs.info add_lv.info calendar_clock.info add_mail_table_entry.info card_access_control.gi.info aim.gi.info card_access_control.info aim_check_.info carriage_return.gi.info aim_util_.info carry_load.info alm.errors.info cb_menu_.info apl.info cb_window_.info apl_erf_.info ccd.info apl_erf_.pl1.info cdq.info apl_ioa_.info cds.info apl_quadcall.info cdw.info apl_read_segment_.info cfsd.info apl_summary.info chaddr.info apl_vs_v1apl.info chalias.info ar.info change.info archive.info change_tuning_parameters.info archive_.info channel_comm_meters.info area_info_.info channel_names.gi.info arg_list.compin.info char_to_numeric_.info argument_list.compin.info character.gi.info assign_resource.info charge.info audit_.gi.info charge_disk.info audit_editor.info chcpass.info backup_preattach.info chdf_proj.info bad_area_format.gi.info check_dir.info bad_area_format.info check_file_system_damage.info before_journal_manager_.info check_file_system_damage_.info before_journal_meters.info check_gate_access_.info before_journal_status.info check_iacl.info bill.info check_sst_size.info bind.changes.info check_tc_data_size.info bj_mgr_call.close.info chname.info bj_mgr_call.closed.info chpass.info bj_mgr_call.create.info chprog.info bj_mgr_call.gdp.info clean_card_pool.info Module Changes for MR11 B-2 SIB11.0 clear_projfile.info cpd.info clear_reqfile.info cpf.info clear_resource.info cpmd.info clock.info cpp.info closed_subsystem.gi.info cr.info clr.info crash.gi.info cls.info create.info cndx.info create_daemon_queues.info cobol.info create_data_segment.info command.gi.info create_dm_file.info command_level.gi.info create_list.info command_line.gi.info create_mail_table.info command_processor.errors.info create_wordlist.info command_processor.gi.info credit.info command_processor_.errors.info cross_ring_.info commands.info csf.info comp.controls.gi.info ctp.info comp.info cu.info compare_pl1.info cu_.info component.gi.info cursor.gi.info component_info_.info cv_cmf.info compose.controls.gi.info cv_dmcf.info compose.info cv_fstime_.info compose_index.info cv_hex_.info compute_bill.info cv_integer_string_.info control_args.gi.info cv_integer_string_check_.info control_argument.gi.info cv_oct_.info control_arguments.gi.info cv_oct_check_.info convert_access_audit_flags_.info cv_rtmf.info convert_access_class_.info cvc.info convert_authorization_.info cwl.info convert_characters.info dac.info convert_configuration_deck.info daily_summary.info convert_forum.info daily_syserr_process.info convert_meetings.ec.info damaged_segments.gi.info convert_old_log.info das.info copy.info date_error.gi.info copy_acl_.info date_time_interval.info copy_as_meters.info dco.info copy_cards.info dcr.info copy_characters.info ddl.info copy_deadproc.info deactivate_seg.info copy_dir.info decode_access_class.info copy_dump_tape.info defer_messages.info copy_file.info delegate.info copy_iacl_seg.info delete_mail_table_entry.info copy_mrds_data.info delete_message.info copy_names_.info delete_proj.info copy_registry.info delete_registry.info copy_switch_off.info delete_search_rules.info count_dict_words.info delete_symbols.info cp.info delete_volume_quota.info cpch.info depd.info Module Changes for MR11 B-3 SIB11.0 describe_entry_type.info dsr.info discard_output.info dsti.info disk_auto.info dti.info disk_meters.info dump_firmware.info disk_report.info eac.info disk_stat_print.info ecr.info disk_usage_stat.info ed_installation_parms.info disklow.info ed_mgt.info display_account_status.info edit_proj.info display_anst.info editing.gi.info display_aut.info eis_tester.info display_cdt.info emacs.changes.info display_cobol_run_unit.info encode_access_class.info display_cpu_error.info enter_carry_request.info display_disk_label.info enter_retrieval_request.info display_dut.info entries.info display_entry_point_dcl.info entry.info display_fnp_idle.info entry_bound.gi.info display_kst_entry.info entry_point.gi.info display_mrds_dm.info entry_point_name.gi.info display_pl1io_error.info entryname.gi.info display_system_audit_flags.info equal_convention.gi.info display_time_info.info err.info dlm.info error_codes.gi.info dlvq.info error_table_conversion.gi.info dm.info et.info dm_display_version.info exclamation_point.gi.info dm_lock_meters.info executive_forum.info dm_lock_status.info executive_mail.errors.info dm_send_request.info exercise_disk.info dm_set_free_area.info exists.info dm_set_journal_stamps.info expand_device_writer.info dm_set_system_dir.info exponent_control.info dm_system_shutdown.info ext_access.info dm_user_shutdown.info extended_access.gi.info dmdm.info extended_acls.gi.info dmisc.info extended_acls.info do_subtree.info extended_entries.gi.info doc.gi.info extended_entries.info doc.info extended_entry_types.info documentation.gi.info fam.info documentation.info fant.info dot_tab_index.compin.info fault.gi.info dpe.info fckm.info dpmf.info ffv1.ec.info dpn.info fig.compin.info dproj.info fig_get_no.compin.info dpunch.info fig_index.compin.info drp.info file.gi.info dsb.info file_manager_.info dset.info fix_quota_used.info dskm.info flsm.info dsl_.info fnp_data_summary.info Module Changes for MR11 B-4 SIB11.0 fnp_throughput.info hierarchy_backup.gi.info format_pl1.info high.info format_string.info home_directory.gi.info fort_typeless.gi.info hour.info fortran.gi.info hp_delete.info fortran.info hp_delete_acl.info fortran_hfp_mode.gi.info hp_delete_vtoce.info forum.info hp_set_acl.info forum.new_features.info hpda.info forum_accept_notifications.info hpdl.info forum_add_meeting.info hpsa.info forum_admin.info hpsdrb.info forum_check_meetings.info hpset_dir_ring_brackets.info forum_find_v1.ec.info hpset_ring_brackets.info forum_list_meetings.info hpsrb.info forum_remove_meeting.info ht.info fp.info hyphenate_word_.info frame.gi.info ibm_pc_io_.info frm.info icpn.info fs_util_.info if.info fstr.info ind.info ft.info indent.info ft_window_.info index.info ftf.errors.info init.compin.info gate.gi.info init_mpm.compin.info gc.gi.info init_photo.compin.info gcos.errors.info init_plm.compin.info gcos.gi.info initiate_file_.info gcos_fms.info install.info gcos_sysprint.info io_error_summary.info gea.info is_component_pathname.info generic_math_.info is_he_user.info ges.errors.info is_legal_proj.info get_dir_quota.info ison.info get_effective_access.info kermit.info get_entry_name_.info kermit_modes.gi.info get_equal_name_.info kermit_server_commands.gi.info get_max_authorization_.info l0toc.compin.info get_mode.info l1exact.compin.info get_pathname.info l1mh.compin.info get_process_authorization_.info l1toc.compin.info get_uid_with_lastname.info l2exact.compin.info gfms.info l2mh.compin.info gpn.info l2toc.compin.info greater.info l3exact.compin.info gsp.info l3mh.compin.info gtss_file_attributes.info l3toc.compin.info hardcore.gi.info l4exact.compin.info hash_table.info l4mh.compin.info hasp_workstation_.info l4toc.compin.info heals_report.info l6_file_transfer_.errors.info help.errors.info l6_ftf.info help_.info l_add_name.info Module Changes for MR11 B-5 SIB11.0 l_delete_name.info ma.info l_patch.info mail.info l_set_acl.info mail_table.gi.info la.info mailbox.gi.info lan.info main_memory_frame.gi.info last_message_destination.info make_commands.info last_message_time.info make_list.info lcp.info making_a_segment_known.gi.info ldd.gi.info manuals.info ldn.info master_directories.gi.info lex_string_.info master_directory.gi.info library_dir_dir.gi.info mc_trace.info library_pathname.info mcc.gi.info limited_service_system.gi.info mct.info link_pair.gi.info mdr.info linkage_section.gi.info memory_units.gi.info linus.changes.info menu_delete.info lisp.changes.info merge_ascii.info lisp.diffs.info message.compin.info lisp.errors.info message_segment.gi.info lisp.manual_update.info message_segments.errors.info lisp_compiler.info message_status.info lisp_difference.gi.info meter_fnp_idle.info list_acl.info meter_gate_.info list_delegated_projects.info metering_util_.info list_dir_info_.info micro_transfer.info list_emacs_ctls.info midbox.compin.info list_entry_types.info min.info list_extra_personids.info mkls.info list_mdir.info ml.info list_output_requests.info mmi_.info list_partitions.info module.compin.info list_proc_required.info monitor_sys_log.info list_vols.info move.info listener.gi.info move_daemon_request.info listform_segment.gi.info move_dir_quota.info listform_segment.info move_log_segments.info lmd.info mpc_data_summary.info lmds.info mrds.builtins.info lmt.info mrds.cmdb_source.info load_control.gi.info mrds.errors.info load_control.info mrds.selection_expressions.info load_ctl_status.info mrds.versions.info load_mpc.info mrpg_limitations.gi.info logical_volume.gi.info ms.errors.info logout_access.info ms_create.info long_year.info ms_delete_acl.info lor.info ms_list_acl.info lpn.info ms_set_acl.info lsa.info mscr.info lset.info msda.info ltrim.info msf.gi.info lv_attaching.gi.info msg.compin.info Module Changes for MR11 B-6 SIB11.0 msgst.info pnt.gi.info msl.info poll_fnp.info msla.info poll_mos_memory.info mssa.info poll_mpc.info mt.info pr.info mtape_.info print.info mtape_delete_defaults.info print_disk.info mtape_get_defaults.info print_error_message.info mtape_set_defaults.info print_heals_message.info multics_card_code.gi.info print_messages.info multiple_names.gi.info print_meters.info multisegment_file.gi.info print_pdt.info mv.info print_projfile.info mvt_.info print_reqfile.info network_request.info print_sat.info new_proj.info print_sys_log.info newline.gi.info print_time_defaults.info ngreater.info print_tuning_parameters.info nondiscretionary_access.gi.info print_urf.info nonmsfs.info print_wordlist.info nonsegments.info priv_move_quota.info nonsegs.info process_overseer_.info nonzero_segments.info proj_mtd.info not.info proj_usage_report.info nr.info psl.info null_links.info ptd.info nzsegs.info ptp.info object_segment.gi.info pur.info ol_dump.info pwl.info option_symbols.info qedx.errors.info osb.info qx.errors.info ov.info rbf_.info overlay.info rc.info pagebox.compin.info rdn.info par_hanging.compin.info rdy.info parse_channel_name_.info read_allowed_.info parse_file_.info read_early_dump_tape.info pas.info ready.info patch_firmware.info ready_on.info pdt_copy.info rebuild_dir.info pel.info reclassify_dir.info pem.info reclassify_seg.info peo.info reclassify_sys_seg.info peol.info reconstruct_registry.info pl1.errors.info record_to_sector.info pl1_code_changes.info recov.info pl1_macro.gi.info redt.info pl1_macro.info register.info plus.info register_mdir.info pm.info release.info pmac.gi.info release_resource.info pmf.info release_temp_segments_.info pmisc.info remote_input_.info Module Changes for MR11 B-7 SIB11.0 remove_registry.info set_tpp.info remove_user.info set_ttt_path.info rename_proj.info set_user_storage.info report_writer_.info setcrank.info request_id_.info setdisk.info reserve_resource.info severity.info reset_cdt_meters.info shortest_path.info reset_disk_meters.info show_symbols.info reset_soos.info signal_io_.info reset_usage.info sm.info reset_use_totals.info sort_projfile.info resetcopysw.info sort_reqfile.info restore_pdt_access.info sort_strings.info reverse_verify.info spc.info rf.info special_active_functions.gi.info rf_comp.differences.info special_active_functions.info rf_comp.diffs.info spg_ring_0_info_.info rl.info spg_util_.info rlr.info sprq.info rqm.info sq.info rsr.info ssb.info run_cobol.info ssc.info runoff.info ssl.info runoff_compose.differences.info sstr.info runtime_symbol_info_.info static_handlers.gi.info rvverify.info static_handlers.info sa.info std.info sac.info stm.info salvage_mstb.info stop_cobol_run.info sample_refs.info stop_run.info save_history_registers.info stpp.info scr.info strip_component.info sdrb.info substr.info search_paths_.info summarize_sys_log.info send_admin_command.info sweep.info send_as_request_.info sweep_disk_.info send_message.info swf.info set_acl.info switch_off.info set_dir_quota.info sys_full_report.info set_dir_ring_brackets.info system_comm_meters.info set_ext_variable_.info system_daily_report.info set_lock_.info system_monthly_report.info set_mos_polling_time.info system_total.info set_proc_required.info ta.changes.info set_quota.info tab_index.compin.info set_sat_audit.info tape.errors.info set_sat_auth.info tape_archive.changes.info set_sons_volume.info tape_i/o.errors.info set_system_audit_flags.info tape_ibm_.info set_system_console.info teco.error_list.status.info set_system_priv.info teco.errors.info set_timax.info teco.info set_time_default.info teco_ssd.info Module Changes for MR11 B-8 SIB11.0 telnet.info usage_total.info terminal_id.info usb.info test_archive.info use_symbols.info test_cpu.info user_ring_io.errors.info test_dcw.info v1_exec_com.info test_fnp.info v1ec.info test_tape.info validate_info_seg.info tid.info value_delete.info time_format.gi.info value_set.info time_strings.gi.info value_set_path.info tp_change_deadline.info values_afs.gi.info tp_display_output_queue.info values_afs.info tp_get_xcn_status.info vdl.info tp_pre_create.ec.info vfa.info tp_pre_create.info vfile_adjust.info tp_stop.info video_editing.gi.info tpdoq.info video_utils_.info tpgxs.info virtual_pointers.gi.info transaction.abandon.info vis.info transaction.abort.info vs.info transaction.begin.info vsp.info transaction.commit.info watch.info transaction.execute.info wcm.info transaction.info wdoc.info transaction.kill.info wh.info transaction.rollback.info where.info transaction.status.info where_doc.info transaction_manager_.info where_search_paths.info translate_aim_attributes_.info who_delg.info truncate_heals_log.info window_call.bell.info tss_fortran.gi.info window_call.change_window.info tss_fortran.info window_call.chgwd.info tty_dump.info window_call.clear_region.info tty_lines.info window_call.clear_window.info tune_disk.info window_call.cleol.info tutorial.info window_call.cleowd.info txn.abandon.info window_call.clrgn.info txn.abort.info window_call.clwd.info txn.begin.info window_call.create_window.info txn.commit.info window_call.crwd.info txn.execute.info window_call.delete_chars.info txn.info window_call.delete_window.info txn.kill.info window_call.dlch.info txn.rollback.info window_call.dlwd.info txn.status.info window_call.gech.info undelegate.info window_call.get_first_line.info underline.info window_call.get_position.info unwire_pages.info window_call.gfl.info up_ctr.info window_call.gouch.info update_heals_log.info window_call.gpos.info update_links.ec.info window_call.gtmhgt.info update_mail_table_entry.info window_call.gtmwid.info upmf.info window_call.guch.info Module Changes for MR11 B-9 SIB11.0 window_call.gwdhgt.info wire_pages.info window_call.insert_text.info work_class_meters.info window_call.itx.info write_acct_bill.info window_call.otx.info write_billing_summary.info window_call.overwrite_text.info write_notify_test.info window_call.revoke.info write_user_usage_report.info window_call.scrgn.info wsp.info window_call.scroll_region.info x.25.status.info window_call.set_position.info x25.errors.info window_call.spos.info xdw.info window_call.sync.info xforum.info window_call.video_invoked.info xmail.errors.info window_call.write_sync_read.info xmodem_io_.info window_call_sposrel.info year.info Module Changes for MR11 B-10 SIB11.0 _N_E_W _S_E_G_M_E_N_T_S _F_O_R _M_R_1_1 accept_messages before_journal_meters access_audit_ before_journal_status access_audit_gate_ bfp_to_hfp_ access_audit_r1_ bj_adopt_txn access_audit_util_ bj_ci_zero access_operations_ bj_cleanup_tables acl_commands_ bj_close_oid aim_util_ bj_flush_pnt ansi_tape_io_ bj_mgr_call as_user_message_ bj_oid_util asum_ bj_open_by_uid asum_create_segment_ bj_ppt_search asum_data_ bj_ppte_create asum_find_segment_ bj_ppte_register asum_inner_ring_caller_ bj_pst_lock asum_read_delete_ops_ bj_pst_search asum_system_init_ bj_pste_create auto.ec bj_pste_delete bce_abs_seg bj_pste_lock bce_alert bj_pste_register bce_appending_simulation bj_report_err bce_check_abort bj_storage_append bce_component_to_wordnum_ bj_storage_flush bce_continue bj_storage_get bce_create_sstnt bj_storage_get_header bce_die bj_storage_put_buffered_ci bce_display_disk_label bj_storage_recycle bce_display_instruction_ bj_storage_util bce_display_scu_ bj_suffix_info_ bce_dump bj_txte_util bce_esd bjm_close bce_exec_com_ bjm_create bce_exec_com_input bjm_data_ bce_execute_command_ bjm_delete bce_get_defptr_ bjm_find_old_uid_pn_table bce_get_flagbox bjm_find_txns_after_crash bce_get_to_command_level bjm_firstref_tv_ bce_inst_length_ bjm_flush_all bce_list_requests_ bjm_flush_transaction bce_listen_ bjm_get_bj_oid bce_map_over_requests_ bjm_get_bj_path_from_oid bce_name_to_segnum_ bjm_get_bj_path_from_uid bce_probe bjm_get_default_bj bce_query_af bjm_get_journal_status bce_ready bjm_no_firstref_tv_ bce_severity bjm_open bce_shutdown_state bjm_open_all_after_crash bce_state bjm_per_process_init_ bce_test_disk bjm_per_system_init_1_ before_journal_manager_ bjm_per_system_init_2_ Module Changes for MR11 B-11 SIB11.0 bjm_rebuild_after_crash cv_fstime_ bjm_rollback cv_integer_string_ bjm_set_default_bj data_format_util_ bjm_user_shutdown date_time_equal bjm_write date_time_interval call_bce dbr_util_ check_file_system_damage dc_find check_gate_access_ defer_messages check_password_ delete_dm_file_ cm_compact delete_message cm_compact_ci describe_entry_type cm_create_collection dfu_cv_attr_to_dim_table cm_create_file dfu_cv_dim_to_dim_table cm_delete dfu_cv_dim_to_field_table cm_delete_buffered dfu_cv_field_to_dim_table cm_delete_cn_datum dfu_cv_tva_to_dim_table cm_destroy_collection disk_reader cm_determine_free_space display_access_class_ cm_find_ci_to_alloc_datum display_disk_label_ cm_find_free_slot display_time_info cm_free_ci dku7102.ctl cm_free_opening_info dm_check_configuration_ cm_get_bci_header dm_compare_shutdown_info cm_get_ci_ptr dm_daemon_gate_ cm_get_element dm_daemon_util_ cm_get_element_buffered dm_data_ cm_get_element_portion dm_display_version cm_get_header dm_dmn_requests_ cm_get_id dm_dmn_system_shutdown_ cm_modify dm_find_configuration_ cm_opening_info dm_firstref_tv_ cm_put dm_firstref_util_ cm_put_basic_element dm_gate_ cm_put_cn_datum dm_gen_checksum_ cm_put_datum_in_place dm_get_daemon_info_ cm_put_datum_in_pool dm_hcs_fake_ cm_put_header dm_hphcs_ cm_put_ordered_element dm_hphcs_fake_ cm_put_overlength_tail dm_init_from_hardcore_ cm_recursive_modify dm_initializer_ cm_replace_buffered_ci dm_lock_configuration_ cm_setup_buffered_ci dm_lock_meters cm_simple_get_element dm_lock_status collection_manager_ dm_misc_util_ collmgr_display dm_no_firstref_tv_ config_deck_data_ dm_no_firstref_util_ config_deck_edit_ dm_per_system_ copy_dm_file_ dm_process_shutdown_spec copy_mrds_data dm_recovery_ create_dm_file dm_request_action_ create_rpv_partition dm_send_request cv_acl_type_ dm_send_request_ cv_dmcf dm_set_free_area Module Changes for MR11 B-12 SIB11.0 dm_set_journal_stamps fm_status dm_set_shutdown_info fm_stream_ dm_set_system_dir fm_sys_pn_tbl_delete dm_shutdown_handler fm_sys_pn_tbl_get_path dm_signal_shutdown_warning fm_sys_pn_tbl_insert dm_signal_user_shutdown fm_sys_pn_tbl_opens dm_system_data_template_ fm_sys_pn_tbl_rename dm_system_shutdown fm_sys_pn_tbl_util_ dm_user_shutdown fm_user_shutdown dm_vector_util_ format_string dm_vu_append_simple_typed fort_bfp_math dm_vu_copy_typed_vector fort_hfp_math dm_vu_err_no_operation forum_conversion_ dm_vu_free_tva forum_et_ dm_vu_free_typed_vector forum_find_v1 dm_vu_init_tva forum_find_v1.ec dm_vu_merge_tva forum_logger_ dmsd_overseer_ forum_mailer_ dmsd_ssu_request_tables_ forum_open_mgr_ dmu_compare_decimal_values forum_salvager_ dmu_compare_sequential forum_space_mgr_ dmu_compare_strings fs_modes dmu_cv_string_to_vector gcos_tape_io_ dmu_cv_typed_array_to_table generic_math_ dmu_cv_vector_to_string get_com_channel_info_ dmu_display_string get_dm_free_area_ dmu_general_modify_string get_effective_access dmu_get_data_bit_length go.ec double_arc_sine_ hardcore_sct_seg dumps.search hc_dm_util_ e_option_defaults_ hc_page_trace emacs.12.4a.sv.lisp hfp_to_bfp_ emacs_.12.4a.sv.lisp ibm_pc_io_ eor_cv7_8_ ibm_tape_io_ establish_temp_segs im_basic_search ffv1.absin im_build_interval_spec ffv1.ec im_compare_subset find_file_partition im_create_cursor find_partition im_create_index fm_combos_ im_create_subset_index fm_create_open_ im_delete_node fm_data_ im_destroy_index fm_delete_close_ im_general_delete fm_do_ im_general_insert fm_firstref_tv_ im_general_search fm_get_ im_get_key_count_array fm_get_last_ci_num im_get_opening_info fm_no_firstref_tv_ im_init_branch_ci_header fm_open_by_uid_ im_init_leaf_ci_header fm_per_process_init_ im_initial_insert fm_per_system_init_ im_make_parent_key fm_prepare_to_copy_ im_process_keys fm_put_ im_put_key Module Changes for MR11 B-13 SIB11.0 im_rotate_insert lm_user_shutdown im_set_cursor lock_manager_ im_simple_delete makeunknown_ im_simple_insert map_onto_disk im_split message_facility_ im_structural_search message_status im_update_branches micro_transfer im_update_key_counts mrds_dsl_compile im_update_opening_info mrds_dsl_set_user_vals index_manager_ ms_salv_util_v4_ init_syserr_log ms_salvager_v4_ init_toehold mseg_check_access_ io_config_init mseg_data_v4_ io_reconfig mseg_operation_ iom_switches mseg_util_v4_ kermit mtape_ kermit_comm_mgr_ mtape_check_status_ kermit_et_ mtape_control_ kermit_get_filenames_ mtape_cv_apd kermit_mode_mgr_ mtape_delete_defaults kermit_pad_ mtape_get_defaults kermit_receive_ mtape_io_ kermit_receive_request_ mtape_iox_ kermit_remote_requests_ mtape_mount_cntl_ kermit_requests_ mtape_position_ kermit_send_ mtape_set_defaults kermit_send_request_ mtape_util_ kermit_server_ multics_tape_io_ kermit_server_request_ om_free_opening kermit_xfer_modes_ om_get_opening l0new.compin om_init l0x.compin om_put_opening last_message_info opening_manager_ limit_covert_channel pa_cv_result_to_lf lister_requests_ pa_get_option_value lm_check_for_deadlock_ pa_get_refname lm_copy_data_ pa_process_arguments lm_data_ pa_search_list lm_expand_lock_seg_ pc_check_tables_ lm_fast_lock_ photo_module_layout.compin lm_fast_lock_list_ print_data_ lm_firstref_tv_ process_arguments_ lm_hash_ raw_tape_io_ lm_init_fast_lock_ rcm_create_collection lm_init_fast_lock_data_ rcm_create_cursor lm_init_fast_per_process_ rcm_delete_record_by_id lm_per_process_ rcm_destroy_collection lm_per_process_init_ rcm_destroy_cursor lm_per_system_ rcm_free_opening_info lm_per_system_init_ rcm_general_search lm_reset_system_meters_ rcm_get_by_spec lm_salvage_lock_seg_ rcm_get_field_info lm_signal_ rcm_get_opening_info Module Changes for MR11 B-14 SIB11.0 rcm_get_record_by_id rw_options rcm_modify_record_by_id rw_requests rcm_process_intervals rw_save_format_options rcm_put_record_by_id rw_set_format_options rcm_update_by_spec rw_temp_seg_mgr rcp_access_kernel_ save_handler_mc rcp_access_kernel_setup sc_create_sci_ rcp_audit sc_edit_motd_ rcp_compute_aim_mode sc_exec_request_ rcp_compute_bracket_mode sc_execute_command_line_ rcp_compute_raw_mode sc_ipc_mask_ rcp_control_ sc_process_command_line_ rcp_merge_modes sc_requests_ rcp_operation_access sc_shutdown_ rcp_setup_event send_as_request_ rcprm_find_op send_message rcprm_registry_util_ send_message_obsolete record_manager_ set_sys_audit_thresholds_ relation_manager_ set_time_default report_writer signal_io_ report_writer_ smarterm.ctl report_writer_info_dirs_ ssu_info_directories_ rlm_create_cursor structure.search rlm_create_index suffix_bj_ rlm_create_relation suffix_forum_ rlm_destroy_cursor syserr_copy rlm_destroy_index syserr_copy_wired_log rlm_destroy_relation syserr_seg_manager rlm_general_search system_shutdown_handler_ rlm_get_approximate_count time_defaults_ rlm_get_cursor_info time_info_ rlm_get_description tm_begin rlm_get_info tm_bump_all rlm_get_tuple_by_id tm_cleanup rlm_open tm_commit rlm_opening_info tm_daemon_adjust rlm_process_tuples_by_id tm_daemon_adopt rlm_put_tuple tm_firstref_tv_ rlm_set_scope tm_generate_txn_id rlm_unimplemented_entries tm_get_current_txn_id rlm_update_opening_info tm_get_state_description rtb.ec tm_get_state_info rw_column_value tm_get_tdt_size rw_define_columns tm_get_txn_index rw_display tm_get_txn_info rw_display_process_args tm_handle_conditions rw_display_scroll tm_ips_wakeup rw_fr_build_page tm_per_process_init_ rw_fr_delete_report tm_per_system_init rw_fr_get_page tm_recover_after_crash rw_fr_new_report tm_rollback rw_list_format_options tm_suspend rw_match_star_name tm_user_shutdown_adjust Module Changes for MR11 B-15 SIB11.0 tm_user_shutdown_free vu_append_general_print tm_user_shutdown_real vu_append_simple_print toehold vu_cv_pva_to_string trace_calibrate_ vu_cv_string_to_pva trace_conversions_ vu_err_no_operation trace_entrypoints_ vu_init_print_vector_array trace_parameters_ vu_replace_print_value trace_tables_ watch trace_time_ x9700_doc.comp_dsm trace_transactions_ x9700_un.comp_dsm transaction x9700_writer_ transaction_manager_ xforum tty_area_manager xforum_create_menu_ update_links.ec xforum_default_fkeys_ user_message_ xforum_dyn_menu_ user_message_admin_ xforum_emacs_ext_ user_message_priv_ xforum_find_path_ v1_forum_gc_ xforum_format_ v1_forum_mgr_ xforum_help_ v1_forum_seg_mgr_ xforum_help_line_ v1_forum_trans_mgr_ xforum_list_meetings_ v2forum_mgr_tv_ xforum_main_options vector_util_ xforum_multics_mode vip7201.ctl xforum_redisplay_ vip7801.comp_dsm xforum_status_ vip7801_writer_ xforum_trans_ volume_registration_cmds_ xforum_window_mgr volume_registration_mgr_ xmail_default_fkeys_ vrm_lock_ xmail_write_msgs_ vt102.ctl xmodem_io_ vu_append_dimension_print Module Changes for MR11 B-16 SIB11.0 _D_E_L_E_T_E_D _S_E_G_M_E_N_T_S _F_O_R _M_R_1_1 add_projfile_entry.ec display_regs_ add_reqfile_entry.ec display_segment_ amu_arglist_ display_stack_ arith_to_arith_ display_syserr_ arith_to_bit_ dmod_ arith_to_char_ dstint audit_gate_ dummy_admin_gate_ azm_display_data_ dump_mc_anstbl azm_format_pointer_ dump_vtoce azm_hran_ enter_admin_mode_ azm_hran_dps8_ execute_sc_command_ azm_hran_l68_ fin_admin_ azm_increment_indices_ find_ bit_to_arith_ find_communications_seg_ bit_to_char_ find_dirsegno bootload_2 find_entry borrow_tty_from_mc_ format_sc1 call_bos fort_math_builtins_ cdir.ec fort_parm_math char_to_arith_ forum_gc_ char_to_bit_ forum_mgr_ char_to_numeric_ get_page_trace check_sst hdx computational_ hvr_ convert_absentee_queues imft_close_acs_list convert_aim_attributes_ imft_open_acs_list convert_audit_ imft_test_acs_list convert_authorization_ imp_attach convert_dprint_msgs imp_cleanup convert_v1_fdump imp_data convert_volume_queues imp_dcm_data copy_from_dump imp_dcm_data_masked cv_MR10_pdts imp_dcm_init cv_MR9_pdts imp_dcm_read cv_MR9_use_totals imp_dcm_write cv_links_to_mail_table imp_get_buffer cv_smf imp_global_queue daily_syserr_process imp_init datmk_util_ imp_input_processor delpag imp_lock device_meters imp_mark_host dir_control_error imp_misc display_am_ imp_order display_ast_ imp_read display_dump_ imp_service display_dump_events imp_status display_frame_args_ imp_status_driver display_label imp_status_wired display_mchist_ imp_tables display_process_ imp_thread Module Changes for MR11 B-17 SIB11.0 imp_util_wired network.object.control imp_wakeup oc_ imp_wired_buffer_ ol_dump imp_write ol_dump_util_ imp_write_service ol_dump_why_ iom_bootload_tape_label old_make_bindmap_ ips_wkp_ pds_trace_ kill_sc_process_ print_aste_ptp languages.control print_dump_tape languages.object.control print_log list_accessible print_syserr_log lister process_dump_segments make_MR8_PNT_URF protection_audit_ make_sys_seg.ec rcp_check_access_ makeunknown rcp_initializer_ mc_write_ rcprm_access_control_ message_facility reformat_mgt monitor_log reset_MR10_pdts mr10.2.make_sys_seg.ec rest_of_datmk_ mrd_tester restart_chn mseg_convert_v3_ return_tty_to_mc_ namef_ save_queues.ec ncp_access_ save_service.ec ncp_connection_ sc_parse_ ncp_control_ set_acl ncp_daemon_ set_flagbox ncp_error_ set_sat_audit ncp_io_ set_sat_auth ncp_lock_ setup_dump_segments ncp_main_ sys_dates_ ncp_order_ syserr_copy_paged ncp_params_ syserr_logger ncp_status_ syserr_select_file ncp_tables_ tape_admin_ ncp_tbl_ tape_master_ ncp_tbop_ time_data_ ncp_trace_ trim_syserr_log ncp_util_ validate_entryp net_ring0_admin_ window_io_video_ net_ring0_sys_ net_ring0_user_ network.control Module Changes for MR11 B-18 SIB11.0 APPENDIX C MR11.0 DATA MANAGEMENT INSTALLATION _I_N_T_R_O_D_U_C_T_I_O_N These are the installation instructions for using the new Data Management (DM) software in Multics Release 11.0 (MR11.0). There are four sections: this introduction, bringing up DM on a new Multics site, bringing up DM on an existing Multics site, and bringing up DM for use on systems using Multics' Access Isolation Mechanism (AIM). It is assumed the reader has read the MR11.0 SRB appendix on DM and the Multics' Reference Manual (Order No. AG91) section on DM. A complete set of manual references can be found in Appendix C of the MR11.0 SRB. DM is not required to boot the MR11.0 system and may be put into operation any time after MR11.0 is running. Any user trying to use a DM file will receive an error indicating DM is not setup to run via the sub_err_ subroutine. _D_M _O_N _A _N_E_W _M_U_L_T_I_C_S _S_I_T_E _P_r_e_p_a_r_i_n_g _t_o _I_n_s_t_a_l_l _D_M THESE INSTRUCTIONS ARE NOT FOR EXISTING SITES. EXISTING SITES PLEASE SEE SECTION TITLED - EXISTING MULTICS SITE AND DM. Before Multics can run DM, >tools>acct_start_up.ec must be run to perform various tasks. These are: - register the user Data_Management on the Daemon project, with the ^vinitproc attribute and a process overseer of >sss>dmsd_overseer_. Sites planning on using AIM should also set the multip attribute. - set read access to the absentee_user_table, daemon_user_table, and answer_table for the above Daemon. MR 11.0 Data Management C-1 SIB11.0 - set read and write access on the bump_user.acs and process_termination_monitor.acs segments in >sc1>admin_acs. The acct_start_up.ec is run from a privileged process by typing: ec >tools>acct_start_up _L_o_g_g_i_n_g _i_n _t_h_e _D_M _D_a_e_m_o_n A sample login line for Data_Management.Daemon has been inserted in >tools>system_start_up.ec and commented out. This is an example only; the DM Daemon's message coordinator ID has no required format. The Daemon should not be allowed to login until the steps below have been completed; if it is, errors will be taken by it's dmsd_overseer_. _M_u_l_t_i_c_s _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 For DM to work, a DBMJ card must be inserted in the Multics configuration before any Multics bootload which uses DM. See the documentation for the DBMJ card in the Multics System Maintenance Procedures Manual (Order No. AM81) for a description of the parameters and examples. The dirlock_writebehind tuning parameter must also be on to guarantee recovery from Multics' system interruption. This may be done by booting Multics with the a PARM DIRW configuration card, or with the change_tuning_parameters command. This parameter is used to keep the file system intact so DM can find any DM protected files to recover. _C_r_e_a_t_i_n_g _t_h_e _D_M _S_y_s_t_e_m _D_i_r_e_c_t_o_r_y Create the directory >site>Data_Management (with the suggested addname of dm). This directory will contain the per-AIM directories (to hold DM bootloads). This directory should contain enough quota for the system_low directory to use; for sites planning on using AIM, enough quota should be assigned to this directory to create per-AIM directories (see "DM with AIM" below). _C_r_e_a_t_i_n_g _t_h_e _s_y_s_t_e_m___l_o_w _D_i_r_e_c_t_o_r_y All site must create the directory "system_low" in >site>Data_Management; it will contain DM information for the system_low AIM classification (the only classification for sites not using AIM). These are the DM configuration table, logs directory, per-bootload directories, and the default before journal. The DM Daemon needs "sma" access to this directory and MR 11.0 Data Management C-2 SIB11.0 all users of DM need "s" access. The contents of this directory are created by the DM Daemon if they do not exist. The before journal generally uses the most quota in system_low; on one system using an 8000 page before journal, the normal quota used for system_low is about 8050 pages. Please note the before journal always uses the same amount of quota whether it is in use or not. On some systems, system_low is a link back to >site>Data_Management. This saves a directory in the heirarchy, but may make maintenance at AIM sites slightly more difficult. If a link in >site>Data_Management is used, the above mentioned ACLs' must be set on >site>Data_Management. _C_r_e_a_t_i_n_g _t_h_e _D_M _C_o_n_f_i_g_u_r_a_t_i_o_n _T_a_b_l_e The file "dm_configuration" must be created in >site>Data_Management>system_low. This is done by creating an ASCII text file with the suffix ".dmcf" and converting it to an "==.dmct" file with the cv_dmcf command. The administrator should then install the ".dmct" by copying it into system_low with a name of "dm_configuration". The DM Daemon will never boot a DM system when the DM configuration table is missing. _L_o_g_i_n _o_f _t_h_e _D_M _D_a_e_m_o_n Now login the DM Daemon. It will automatically create the DM logs directory and default before journal. The system_start_up.ec should be changed to login the Daemon automatically; it should also have routings given for the output of the Daemon. See the System Maintenance Procedures manual (Order No. AM81) for an example of the routings used on a system currently using DM. _E_X_I_S_T_I_N_G _M_U_L_T_I_C_S _S_I_T_E _A_N_D _D_M _U_p_d_a_t_i_n_g _S_y_s_t_e_m _T_a_b_l_e_s _a_n_d _A_c_c_e_s_s Before Multics can run DM, several changes are required to create some new system segments, add a new user to the system, and provide the new user with access to certain system tables. These are: - register the user Data_Management on the Daemon project, with the ^vinitproc attribute and a process overseer of >sss>dmsd_overseer_. AIM sites should also set the multip attribute. MR 11.0 Data Management C-3 SIB11.0 - set read access to the absentee_user_table, daemon_user_table, and answer_table for the above Daemon. - set read and write access on the bump_user.acs and process_termination_monitor.acs segments in >sc1>admin_acs, creating these segments if they do not exist. _L_o_g_i_n _o_f _t_h_e _D_M _D_a_e_m_o_n A sample login line for Data_Management.Daemon been has inserted in >tools>system_start_up.ec and commented out. This is an example only; the DM Daemon's message coordinator ID has no required format. The Daemon should not be allowed to login until the steps below have been completed; if it is, errors will be taken by it's dmsd_overseer_. _M_u_l_t_i_c_s _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 For DM to work, a DBMJ card must be inserted in the Multics configuration before any Multics bootload which uses DM. See the documentation for the DBMJ card in the Multics System Maintenance Procedures Manual (Order No. AM81) for a description of the parameters and examples. The dirlock_writebehind tuning parameter must also be on to guarantee recovery from Multics' system interruption. This may be done by booting Multics with the a PARM DIRW configuration card, or with the change_tuning_parameters command. This parameter is used to keep the file system intact so DM can find any DM protected files to recover. _C_r_e_a_t_i_n_g _t_h_e _D_M _S_y_s_t_e_m _D_i_r_e_c_t_o_r_y Create the directory >site>Data_Management (with the suggested addname of dm). This directory will contain the per-AIM directories (to hold DM bootloads). This directory should contain enough quota for the system_low directory to use; for sites planning on using AIM, enough quota should be assigned to this directory to create per-AIM directories (see "DM with AIM" below). _C_r_e_a_t_i_n_g _t_h_e _s_y_s_t_e_m___l_o_w _D_i_r_e_c_t_o_r_y All sites must create the directory "system_low" in >site>Data_Management; it will contain DM information for the system_low AIM classification (the only classification for sites not using AIM). These are the DM configuration table, the DM logs directory, per-bootload directories, and the default before journal. The DM Daemon needs "sma" access to this directory and MR 11.0 Data Management C-4 SIB11.0 all users of DM need "s" access. The contents of this directory are created by the DM Daemon if they do not exist. The before journal generally uses the most quota in system_low; on one system using an 8000 page before journal, the normal quota used for system_low is about 8050 pages. Please note the before journal always uses the same amount of quota whether it is in use or not. On some systems, system_low is a link back to >site>Data_Management. This saves a directory in the heirarchy, but may make maintenance at AIM sites slightly more difficult. If a link in >site>Data_Management is used, the above mentioned ACLs' must be set on >site>Data_Management. _C_r_e_a_t_i_n_g _t_h_e _D_M _c_o_n_f_i_g_u_r_a_t_i_o_n _t_a_b_l_e The file "dm_configuration" must be created in >site>Data_Management>system_low. This is done by creating an ASCII text file with the suffix ".dmcf" and converting it to an "==.dmct" file with the cv_dmcf command. The administrator should then install the ".dmct" by copying it into system_low with a name of "dm_configuration". The DM Daemon will never boot a DM system when the DM configuration table is missing. _L_o_g_i_n _o_f _t_h_e _D_M _D_a_e_m_o_n Now login the DM Daemon. It will automatically create the DM logs directory and default before journal. The system_start_up.ec should be changed to login the Daemon automatically; it should also have routings given for the output of the Daemon. See the System Maintenance Procedures manual (Order No. AM81) for an example of the routings used on a system currently using DM. _R_E_L_A_T_I_O_N_S_H_I_P _O_F _A_I_M _A_N_D _D_M For those sites running Multics with multiple AIM classification in use, special action must be taken to set up Data Management. In MR11, there is one DM system per AIM classification; the system_low directory is the per-AIM directory for the classification of AIM level zero and no categories. A directory under >site>Data_Managment must be created for each AIM classification with which DM will be used. The name of these directories is obtained from the convert_access_class_$encode subroutine (or its command interface encode_access_class). The following are the steps required to create each of these directories: MR 11.0 Data Management C-5 SIB11.0 1) While logged in at the access class of the >site>Data_Management directory, execute the command do "create_dir [encode_access_class &r1] -acc &r1 -quota &2" where the first argument to the command line is the desired classification at which to run DM and the second is the quota to be moved from >site>Data_Management to the per-AIM directory. Care must be taken to ensure enough quota is provided for the the system default before journal, etc. 2) Login at the desired AIM classification and create the configuration file in the per-AIM directory as outlined for the system_low directory above. 3) Make sure the DM Daemon registration allows the Daemon to login at the desired minimum and maximum AIM classifications. Also, verify the multip attribute is on as one Daemon per AIM classification is required. Setup the system_start_up.ec to automatically login the DM Daemons at the desired classifications. 4) Login the DM Daemon at the newly setup AIM classification. This will create the various directories and segments (except the configuration file) under the per-AIM directory and open DM for users of databases logged in at the classification. MR 11.0 Data Management C-6 SIB11.0 APPENDIX D FORMATTING DISKS WITH MTR This appendix describes a procedure for formatting disk packs using the Media Test Routines (MTRs). The procedure utilizes an annotated script which shows typical input and output. Because the formatting procedures differ for MSU0451 and MSU0500/0501 devices, separate scripts are provided. In the scripts, input typed by the user is preceded by a ox (bullet). _F_O_R_M_A_T_T_I_N_G _M_S_U_0_4_5_1 _D_I_S_K _P_A_C_K_S The following script shows how to run MTR tests 6 and 3 to format and test an MSU0451 disk pack, and to assign alternates to tracks found defective during testing. 1. Enter the Total OnLine Test System (TOLTS): ox bound_tolts_$tolts_ ***tolts executive version 810301 on 820812 at 20.071 2. Enter the MPC OnLine Test Subsystem (MOLTS): ***enter "polts", "molts", "colts", "isolts", "quit", or "msg" ??? ox molts Formatting Disks With MTR D-1 SIB11.0 3. List the disk configuration for the disk string which formatting will be done (because of page constraints, the following message is not an exact copy of that which is displayed by the system): ??? ox test pcd peripheral configuration: dska 451 16 units; starting with device no. 1 020xx primary channel of 4 logical channels on mpc mspa 026xx secondary channel of 4 logical channels on mpc mspa 124xx secondary channel of 4 logical channels on mpc mspb 122xx secondary channel of 4 logical channels on mpc mspb 4. Enter MTR test 6 to format and test the MSU0451 device: ??? ox test mmt12020t6 where "test mmt12020t6" is a sample of the input format "test mmtICCDDtT": mmt identifies the MTR test package ICC gives the IOM number (0 = IOM A, 1 = IOM B, etc) and channel number (in decimal) of a channel by which the device to be formatted can be addressed. It must be one of those shown in the output of "test pcd" in step 3. In the sample input above, "120" is IOM B, channel 20. DD gives the device number (in decimal) of the device to be tested. In the sample input, it is device 20 (dskb_20). T gives the number of the MTR test to be run. In this case, test 6 should be run to format/test a pack. Formatting Disks With MTR D-2 SIB11.0 5. The following output describes steps taken by MTR test 6 to attach the disk drive and mount the pack for writing: ***molts executive versions 820601 820701 on 820812 at 19.97 **0(mmt12020) short wait, allocation queued **0(mmt12020) start tmt65a-rmc1, ttldat 820331, phy./log. id t//04 **0(mmt12020) start tmt65b-rmc2, ttldat 820331, phy./log. id t//04 **0(mmt12020) start tmt65c-rmc3, ttldat 820401, phy./log. id t//04 **0(mmt12020) start tmt65d-rmc4, ttldat 820405, phy./log. id t//04 **0(mmt12020) start tmt65e-rmc5, ttldat 820421, phy./log. id t//04 **0(mmt12020) start tmt65f-rmc6, ttldat 820331, phy./log. id t//04 **0(mmt12020) rmc6 is at your service to format a disk pack - **0(mmt12020) ***** write permission granted ***** **0(mmt12020) ***** begin format pack ***** the test will format all tracks on the pack. format will defined by device type. bad tracks will be marked defective (no alt. assigned). **0(mmt12020) system device code = .ds450 6. Answer MTR initialization questions (not a restart, normal formatting, and use 3 write patterns during testing): **0(mmt12020) is this a restart? enter (y or n) - ox n **0(mmt12020) select (f)ast or (n)ormal format? (f)ast format is designed for data security erase and/or test purposes. (n)ormal format is designed for disk packs that are going to be used in systems applications. enter (f or n) - ox n **0(mmt12020) select from "1" to "7" write patterns? enter (1 thru 7) - ox 3 7. At this point, formatting of the pack begins: **0(mmt12020) ***** begin disk pack format ***** Formatting Disks With MTR D-3 SIB11.0 8. After the message in Step 7 is displayed, press the BREAK key to interrupt formatting operations. When MOLTS prompts for input, set test options to: report the current cylinder/head (CCC/HH) address; display CCC/HH for transient errors; report test progress every 100 cylinders, with summary reports attached. ox ??? ox test momt12020.r where "test momt12020.r" is a sample of the input format "test momtICCDD.O": momt identifies request to set options ICCDD are the IOM, Channel and Device numbers given in Step 4. .r is the first option, to report current CCC/HH location. Set the remaining options when prompted: *0(mmt12020) t6 enter options: ox .i *0(mmt12020) t6 enter options: ox .e *0(mmt12020) t6 enter options: ox .s *0(mmt12020) t6 enter options: ox .t *0(mmt12020) t6 enter options: ox .go 9. When the .go option is entered in Step 8, MTR reports the current location being formatted and displays the defective tracks found. It then asks if you want to continue formatting: **0(mmt12020) format function current addr. = 007/00 **0(mmt12020) format function current addr. = 007/00 **0(mmt12020) ***** rmc6 - summary report ***** no tracks were formatted defective **0(mmt12020) do you want the test to continue? enter (y or n) - ox y Formatting Disks With MTR D-4 SIB11.0 10. After every 100 cylinders are formatted, MTR displays defective tracks found. For example, the final summary displayed just before formatting completes, looks like: **0(mmt12020) rmc6 has formatted tracks "000/00 thru 700/00" **0(mmt12020) ***** rmc6 - summary report ***** no tracks were formatted defective **0(mmt12020) rmc6 has formatted tracks "000/00 thru 800/00" **0(mmt12020) ***** rmc6 - summary report ***** no tracks were formatted defective **0(mmt12020) ***** disk pack format complete ***** 11. After formatting is complete, MTR begins testing the tracks on the formatted pack. Defective tracks are usually encountered only during the testing phase. Error summaries are displayed after every 100 cylinders have been tested. start media test phase **0(mmt12020) rmc6 has tested tracks "000/00 thru 100/00" **0(mmt12020) ***** rmc6 - summary report ***** no tracks were formatted defective **0(mmt12020) rmc6 has tested tracks "000/00 thru 200/00" **0(mmt12020) ***** rmc6 - summary report ***** no tracks were formatted defective **0(mmt12020) rmc6 has tested tracks "000/00 thru 300/00" **0(mmt12020) ***** rmc6 - summary report ***** defective - marginal data field on std track 217/10 **0(mmt12020) ***** rmc6 - summary report ***** defective - unrec. data field on std track 244/06,245/06 **0(mmt12020) ***** rmc6 - summary report ***** reclaimed - reformatted and certified 246/06 Formatting Disks With MTR D-5 SIB11.0 12. When testing is complete, termination summary reports are displayed: **0(mmt12020) ***** normal termination summary reports ***** **0(mmt12020) ***** rmc6 - summary report ***** defective - marginal data field on std track 217/10 **0(mmt12020) ***** rmc6 - summary report ***** defective - unrec. data field on std track 244/06,245/06 **0(mmt12020) ***** rmc6 - summary report ***** reclaimed - reformatted and certified 246/06 13. MTR then asks if you want to select a new test (answer "y" for yes): **0(mmt12020) want to select a new test? enter (y or n) - ox y 14. MTR then displays information describing how to select the next test: **0(mmt12020) rmc6 will go into waiting! select test (t1 thru t6) enter test no. thru standard option call (test momticcddtx) - **0(mmt12020) waiting Formatting Disks With MTR D-6 SIB11.0 15. To actually select the next test, press the BREAK key and wait for the MOLTS prompt. Then select test 3, which assigns alternate tracks for those tracks found to be defective above. ox ??? ox test momt12020t3 where "test momt12020t3" is a sample of the input format "test momtICCDDtT": momt identifies request to set options ICCDD are the IOM, Channel and Device numbers given in Step 4. tT gives the number of the next test to run. Test 3 initialization displays the following information: **0(mmt12020) start tmt65e-rmc5, ttldat 820421, phy./log. id t//04 **0(mmt12020) start tmt65d-rmc4, ttldat 820405, phy./log. id t//04 **0(mmt12020) start tmt65c-rmc3, ttldat 820401, phy./log. id t//04 16. Select subtest 4 of test 3, to assign alternates to all defective tracks: **0(mmt12020) rmc3 is at your service for track and cylinder reformat - select a sub test a) subtst 1 - reformat 1 track (good) b) subtst 2 - reformat 1 cylinder (good) c) subtst 3 - reformat 1 track (defective) d) subtst 4 - assign alternate tracks enter (1 thru 4) - ox 4 Formatting Disks With MTR D-7 SIB11.0 17. MTR then briefly describes the subtest, and asks if you want to continue (answer "y" for yes) **0(mmt12020) ***** begin subtst 4 ***** assign alternate tracks on the device a) subtst will search thru all standard tracks looking for tracks marked defective (no alternate assigned). b) when a track marked defective (no alternate assigned) is detected, the subtst will stop and process this track. c) the alternate track processor will go out to the alternate track cylinders and find the first available alternate. it will mark the track as assigned alternate. then it will mark the standard track as defective (alt. assigned). d) the search process will terminate after the last standard track completes testing and/or processing. do you want the subtst to continue? enter (y or n) - ox y 18. MTR then asks for permission to overwrite the pack's label (answer "y" for yes): **0(mmt12020) ***** rmc3 - label obliterate warning ***** all sub tests in rmc3 will overwrite the system label on track zero. do you want the sub test to continue? enter (y or n) - ox y 19. MTR then asks if you are restarting (answer "n" for no): **0(mmt12020) system device code = .ds450 **0(mmt12020) is this a restart? enter (y or n) - ox n 20. MTR then begins displaying summary reports after every 100 cylinders are checked for alternate assignments: **0(mmt12020) rmc3 has tested tracks "000/00 thru 200/00" **0(mmt12020) ***** rmc3 - subtst 4 summary report ***** no alternate tracks were assigned **0(mmt12020) rmc3 has tested tracks "000/00 thru 300/00" **0(mmt12020) ***** rmc3 - subtst 4 summary report ***** defective - alt assigned def alt def alt cyl/hd cyl/hd cyl/hd cyl/hd 217/10 811/00 244/06 811/01 245/06 811/02 Formatting Disks With MTR D-8 SIB11.0 21. After alternate assignments are complete, MTR displays a summary report describing all alternates on the pack: **0(mmt12020) ***** normal termination summary reports ***** **0(mmt12020) ***** rmc3 - subtst 4 summary report ***** defective - alt assigned def alt def alt cyl/hd cyl/hd cyl/hd cyl/hd 217/10 811/00 244/06 811/01 245/06 811/02 22. MTR then asks if you want to select a new test (answer "n" for no, and "quit" to exit from TOLTS). **0(mmt12020) want to select a new test? enter (y or n) - ox n **0(mmt12020) normal term 1 ***molts executive version 820701 off 820812 at 21.45 p.t. 119530 ***enter "polts", "molts", "colts", "isolts", "quit", or "msg" ??? ox quit ***tolts executive version 810301 off 820812 at 21.375 r 21:37 1107.348 1162 Formatting Disks With MTR D-9 SIB11.0 _F_O_R_M_A_T_T_I_N_G _M_S_U_0_5_0_0_/_M_S_U_0_5_0_1 _D_I_S_K _P_A_C_K_S The following script shows how to run MTR tests 6 and 7 to format and test an MSU0500 or MSU0501 disk drive, and to assign alternates to tracks found defective during testing. The MPC normally treats an MSU0500 or MSU0501 disk drive as two separately addressable devices. However, MTR formats and tests both logical devices during a single invocation, referring to one as the "odd device" (e.g., dskc_27) and the second as the "even device" (e.g., dskc_28). MTR refers to both logical devices as a single "head assembly" or "hda". 1. Enter the Total OnLine Test System (TOLTS): ox bound_tolts_$tolts_ ***tolts executive version 810301 on 820812 at 20.071 2. Enter the MPC OnLine Test Subsystem (MOLTS): ***enter "polts", "molts", "colts", "isolts", "quit", or "msg" ??? ox molts 3. List the disk configuration: ??? ox test pcd peripheral configuration: dskc 501 32 units; starting with device no. 1 028xx primary channel of 4 logical channels on mpc mspc 030xx secondary channel of 4 logical channels on mpc mspc 130xx secondary channel of 4 logical channels on mpc mspd 128xx primary channel of 4 logical channels on mpc mspd Formatting Disks With MTR D-10 SIB11.0 4. Enter MTR test 6 to format and test the entire MSU0500 or MSU0501 device: ??? ox test mmt12827t6 where "test mmt12827t6" is a sample of the input format "test mmtICCDDtT": mmt identifies the MTR test package ICC gives the IOM number (0 = IOM A, 1 = IOM B, etc) and channel number (in decimal) of achannel by which the device to be formatted can be addressed.It must be one of those shown in the output of "test pcd" in step 3. In the sample input above, "128" is IOM B, channel 28. DD gives the device number (in decimal) of the device to be tested. In the sample input, it is device 27 (dskc_27). Always give the device number of the "odd device" associated with the disk drive. T gives the number of the MTR test to be run. In this case, test 6 should be run to format/test the drive. 5. The following output describes steps taken by MTR test 6 to attach the disk drive for writing: ***molts executive versions 820601 820701 on 820805 at 20.08 **0(mmt12827) short wait, allocation queued **0(mmt12827) short wait, allocation queued **0(mmt12827) start tmt67a-mtr1, ttldat 820401, phy./log. id t//04 **0(mmt12827) start tmt67b-mtr2, ttldat 820401, phy./log. id t//04 **0(mmt12827) start tmt67c-mtr3, ttldat 820402, phy./log. id t//04 **0(mmt12827) start tmt67d-mtr4, ttldat 820405, phy./log. id t//04 **0(mmt12827) start tmt67e-mtr5, ttldat 820421, phy./log. id t//04 **0(mmt12827) start tmt67f-mtr6, ttldat 820405, phy./log. id t//04 **0(mmt12827) mtr6 is at your service to format a physical device - **0(mmt12827) ***** write permission granted ***** **0(mmt12827) ***** begin upgrade/downgrade hda ***** the test will format all tracks on the hda. the format will be defined by device type. bad tracks will be marked defective (no alternate). Formatting Disks With MTR D-11 SIB11.0 6. Answer MTR initialization questions (ok to format with 512 words per sector, not a restart, normal formatting, and use 3 write patterns during testing): **0(mmt12827) device pair are configured as msu0501's the hda will be formatted in (512) words/sector. is this correct? enter (y or n) - ox y **0(mmt12827) is this a restart? enter (y or n) - ox n **0(mmt12827) select (f)ast or (n)ormal format? (f)ast format is designed for data security erase and/or test purposes. (n)ormal format is designed for hda's to be used in systems applications. enter (f or n) - ox n **0(mmt12827) select from "1" to "7" write patterns? enter (1 thru 7) - ox 3 7. At this point, formatting of the pack begins: **0(mmt12827) ***** begin hda format ***** Formatting Disks With MTR D-12 SIB11.0 8. After the message in Step 7 is displayed, press the BREAK key to interrupt formatting operations. When MOLTS prompts for input, set test options to: report the current cylinder/head (CCC/HH) address; display CCC/HH for transient errors; report test progress every 100 cylinders, with summary reports attached. ox ??? ox test momt12827.t where "test momt12020.r" is a sample of the input format "test momtICCDD.O": momt identifies request to set options ICCDD are the IOM, Channel and Device numbers given in Step 4. .r is the first option, to report current CCC/HH location. Set the remaining options when prompted: *0(mmt12827) t6 enter options: ox .e *0(mmt12827) t6 enter options: ox .s *0(mmt12827) t6 enter options: ox .i *0(mmt12827) t6 enter options: ox .r *0(mmt12827) t6 enter options: ox .go Formatting Disks With MTR D-13 SIB11.0 9. When the .go option is entered in Step 8, MTR reports the current location being formatted and displays the defective tracks found. It then asks if you want to continue formatting: **0(mmt12827) format function current addr. = 004/00 **0(mmt12827) format function current addr. = 004/00 **0(mmt12827) ***** statistics from format of hda ***** summary for msu0501 devices (27/28) no. of tracks with 1 defect skip = 1 no. of tracks with 2 defect skips = 0 no. of tracks with 3 defect skips = 0 no. of new defect skips generated = 0 total defect skips processed = 1 odd device defective tracks = 0 even device defective tracks = 0 physical device defective tracks = 0 total = 0 **0(mmt12827) ***** mtr6 - hda condition summary report ***** no tracks were marked defective. **0(mmt12827) do you want the test to continue? enter (y or n) - ox y Formatting Disks With MTR D-14 SIB11.0 10. After every 100 cylinders are formatted, MTR displays defective tracks found. For example, the final summary displayed just before formatting completes, looks like: **0(mmt12827) mtr6 has formatted tracks "000/00 thru 800/00" **0(mmt12827) ***** mtr6 - hda condition summary report ***** --- msu0501 odd device report (27) --- defective - error logging track info 006/19,028/19,284/01,370/12 **0(mmt12827) ***** mtr6 - hda condition summary report ***** --- msu0501 even device report (28) --- defective - error logging track info 008/19,026/19,096/05,174/16,381/06,736/09,778/19 **0(mmt12827) ***** statistics from format of hda ***** summary for msu0501 devices (27/28) no. of tracks with 1 defect skip = 33 no. of tracks with 2 defect skips = 2 no. of tracks with 3 defect skips = 0 no. of new defect skips generated = 0 total defect skips processed = 37 odd device defective tracks = 4 even device defective tracks = 7 physical device defective tracks = 0 total = 11 **0(mmt12827) ***** hda format complete ***** Formatting Disks With MTR D-15 SIB11.0 11. After formatting is complete, MTR begins testing the tracks on the formatted pack. Error summaries are displayed after every 100 cylinders have been tested. start media test phase **0(mmt12827) mtr6 has tested tracks "000/00 thru 100/00" **0(mmt12827) ***** mtr6 - hda condition summary report ***** --- msu0501 odd device report (27) --- defective - error logging track info 006/19,028/19,284/01,370/12,816/04,818/04,832/04 **0(mmt12827) ***** mtr6 - hda condition summary report ***** --- msu0501 even device report (28) --- defective - error logging track info 008/19,026/19,096/05,174/16,381/06,736/09,778/19 **0(mmt12827) ***** mtr6 - hda condition summary report ***** --- msu0501 even device report (28) --- reclaimed - repaired data field 042/15 **0(mmt12827) ***** statistics from format of hda ***** summary for msu0501 devices (27/28) no. of tracks with 1 defect skip = 42 no. of tracks with 2 defect skips = 2 no. of tracks with 3 defect skips = 0 no. of new defect skips generated = 1 total defect skips processed = 47 odd device defective tracks = 7 even device defective tracks = 7 physical device defective tracks = 0 total = 14 Formatting Disks With MTR D-16 SIB11.0 12. When testing is complete, termination summary reports are displayed: **0(mmt12827) ***** normal termination summary reports ***** **0(mmt12827) ***** mtr6 - hda condition summary report ***** --- msu0501 odd device report (27) --- defective - error logging track info 006/19,028/19,284/01,370/12,816/04,818/04,832/04 **0(mmt12827) ***** mtr6 - hda condition summary report ***** --- msu0501 odd device report (27) --- reclaimed - repaired data field 764/09,830/04 **0(mmt12827) ***** mtr6 - hda condition summary report ***** --- msu0501 even device report (28) --- defective - error logging track info 008/19,026/19,096/05,174/16,381/06,736/09,778/19 **0(mmt12827) ***** mtr6 - hda condition summary report ***** --- msu0501 even device report (28) --- reclaimed - repaired data field 042/15,762/09,818/08 **0(mmt12827) ***** statistics from format of hda ***** summary for msu0501 devices (27/28) no. of tracks with 1 defect skip = 42 no. of tracks with 2 defect skips = 2 no. of tracks with 3 defect skips = 0 no. of new defect skips generated = 5 total defect skips processed = 51 odd device defective tracks = 7 even device defective tracks = 7 physical device defective tracks = 0 total = 14 13. MTR then asks if you want to select a new test (answer "y" for yes) **0(mmt12827) want to select a new test? enter (y or n) - ox y Formatting Disks With MTR D-17 SIB11.0 14. MTR then displays information describing how to select the next test: **0(mmt12827) mtr6 will go into waiting! select test (t1 thru t7) enter test no. thru standard option call (test momticcddtx) - **0(mmt12827) waiting 15. To actually select the next test, press the BREAK key and wait for the MOLTS prompt. Then select test 7, which assigns alternate tracks for those tracks found to be defective above. Test 7 assigns alternates for the complete head assembly, whereas test 3 (used in the procedure for formatting MSU0451 disks) only assigns alternates for a single logical device. Thus, test 3 would have to be run twice (once for the odd device and once for the even device) to assign alternates on an MSU0500 or MSU0501 disk. ox ??? ox test momt12827t7 where "test momt12827t7" is a sample of the input format "test momtICCDDtT": momt identifies request to set options ICCDD are the IOM, Channel and Device numbers given in Step 4. tT gives the number of the next test to run. Test 7 initialization displays the following information: **0(mmt12827) start tmt67g-mtr7, ttldat 820405, phy./log. id t//04 16. Select subtest 1 of test 7, to assign alternates to all defective tracks: **0(mmt12827) mtr7 is at your service for special physical device formatting - select the subtst a) subtst 1 - assign all alternate tracks b) subtst 2 - create & write logging tracks enter (1 thru 2) - ox 1 Formatting Disks With MTR D-18 SIB11.0 17. MTR then briefly describes the subtest, and asks if you want to continue (answer "y" for yes): **0(mmt12827) ***** begin subtst 1 ***** assign alternate tracks on the physical device the subtst will search "all" standard tracks on the hda for defective (no alt. assigned). if any are found, it will assign the 1st available alternate to them. **0(mmt12827) do you want subtst (1) to continue? enter (y or n) - ox y 18. MTR then asks if you are restarting (answer "n" for no): **0(mmt12827) is this a restart? enter (y or n) - ox n 19. MTR then begins displaying summary reports after every 100 cylinders are checked for alternate assignments: **0(mmt12827) mtr7 has processed tracks "000/00 thru 100/00" **0(mmt12827) ***** mtr7 - subtst 1 summary report ***** --- msu0501 odd device report (27) --- defective - alternate track assigned def alt def alt cyl/hd cyl/hd cyl/hd cyl/hd 006/19 840/00 028/19 840/03 **0(mmt12827) ***** mtr7 - subtst 1 summary report ***** --- msu0501 even device report (28) --- defective - alternate track assigned def alt def alt cyl/hd cyl/hd cyl/hd cyl/hd 008/19 840/01 026/19 840/02 096/05 840/04 Formatting Disks With MTR D-19 SIB11.0 20. After alternate assignments are complete, MTR displays a summary report describing all alternates on the pack: **0(mmt12827) ***** normal termination summary reports ***** **0(mmt12827) ***** mtr7 - subtst 1 summary report ***** --- msu0501 odd device report (27) --- defective - alternate track assigned def alt def alt cyl/hd cyl/hd cyl/hd cyl/hd 006/19 840/00 028/19 840/03 284/01 840/06 370/12 840/07 816/04 840/11 818/04 840/12 832/04 840/13 **0(mmt12827) ***** mtr7 - subtst 1 summary report ***** --- msu0501 even device report (28) --- defective - alternate track assigned def alt def alt cyl/hd cyl/hd cyl/hd cyl/hd 008/19 840/01 026/19 840/02 096/05 840/04 174/16 840/05 381/06 840/08 736/09 840/09 778/19 840/10 21. MTR then asks if you want to select a new test (answer "n" for no, and "quit" to exit TOLTS). **0(mmt12827) want to select a new test? enter (y or n) - ox n **0(mmt12827) normal term 1 ***molts executive version 820701 off 820806 at 00.27 p.t. 5185916 ***enter "polts", "molts", "colts", "isolts", "quit", or "msg" ??? ox quit ***tolts executive version 810301 off 820806 at 00.165 r 00:16 5188.584 1038 D-20 SIB11.0 CONTENTS Page Section 1 Introduction . . . . . . . . . . . . . . 1-1 Site Support . . . . . . . . . . . . . 1-1 Section 2 Description of Package . . . . . . . . . 2-1 Library Naming Conventions . . . . . . 2-1 Contents of MR11 Package . . . . . . . 2-2 Section 3 FCO and Firmware Status . . . . . . . . . 3-1 Firmware . . . . . . . . . . . . . . . 3-1 Field Change Order List . . . . . . . 3-2 Section 4 Instructions for Sites Updating to MR11 from MR10.2 . . . . . . . . . . . . . . 4-1 _S_I_G_N_I_F_I_C_A_N_T _C_H_A_N_G_E_S _I_N _T_H_I_S _R_E_L_E_A_S_E . 4-2 Step 1: Pre-Installation Preparation 4-4 Step 2: Installation Instructions . . 4-7 Automatic Partition Creation . . . 4-7 Manual Partition Creation . . . . . 4-8 Step 3: Preparation for MR11 Installation . . . . . . . . . . . . 4-9 Step 4: Installation of BCE . . . . . 4-11 Step 5: Changes to Config Deck . . . 4-12 Step 6: Ring-1 Environment . . . . . 4-13 Step 7: FNP Core Images and CMF Conversion . . . . . . . . . . . . . 4-17 Step 8: TTF Conversion . . . . . . . 4-19 Step 9: ACLs and Ring Brackets . . . 4-19 Step 10: Volume Information and Operator Login and Log Commands . . . 4-21 Step 11: System Cleanup . . . . . . . 4-22 Step 12: Forum Installation . . . . . 4-23 Section 5 Instructions for Sites Installing for First Time . . . . . . . . . . . . . . . 5-1 Step 1: Preparation . . . . . . . . . 5-1 Step 2: Logical Volume Assignments . 5-2 Step 3: RPV Initialization . . . . . 5-4 Step 4: Configuration . . . . . . . . 5-5 Step 5: Initializing Root Volumes . . 5-7 Step 6: Additional Configuration Parameters . . . . . . . . . . . . . 5-8 iii SIB11.0 CONTENTS (cont) Page Step 7: Reload of Executable Libraries . . . . . . . . . . . . . . 5-8 Step 8: Setting and Checking Access . 5-9 Step 9: Setting Volume Quota . . . . 5-10 Step 10: Reload of Remaining Release Tapes . . . . . . . . . . . . . . . . 5-12 Step 11: Running acct_start_up.ec . . 5-12 Step 12: Multics Communications System . . . . . . . . . . . . . . . 5-13 Section 6 Instructions for Sites Updating to MR11 from MR10.1 . . . . . . . . . . . . . . 6-1 SIGNIFICANT CHANGES IN THIS RELEASE . 6-2 Step 1: Pre-Installation Preparation 6-4 Step 2: Installation Instructions . . 6-6 Automatic Partition Creation . . . 6-7 Manual Partition Creation . . . . . 6-7 Step 3: Preparation for MR11 Installation . . . . . . . . . . . . 6-8 Step 4: Installation of BCE . . . . . 6-10 Step 5: Changes to Config Deck . . . 6-11 Step 6: Ring-1 Environment . . . . . 6-15 Step 7: Converting System Logs . . 6-21 Step 8: FNP Core Images and CMF Conversion . . . . . . . . . . . . . 6-23 Step 9: TTF Conversion . . . . . . . 6-25 Step 9: ACLs and Ring Brackets . . . 6-26 Step 10: Volume Information and Operator Login . . . . . . . . . . . 6-27 Step 11: System Cleanup . . . . . . . 6-29 Step 12: Forum Installation . . . . . 6-29 Appendix A Bootload Multics (BCE) . . . . . . . . . A-1 The MST . . . . . . . . . . . . . . . A-1 Booting . . . . . . . . . . . . . . . A-2 Booting BCE From BOS . . . . . . . . . A-2 Booting BCE From the IOM . . . . . . . A-3 Normal Operation of BCE . . . . . . . A-5 State of the System . . . . . . . . . A-5 The Toehold and Executing Switches . . A-6 General Operation of BCE . . . . . . . A-7 Appendix B Module Changes for MR11 . . . . . . . . . B-1 New Info Segments for MR11 . . . . . . B-2 New Segments for MR11 . . . . . . . . B-11 Deleted Segments for MR11 . . . . . . B-17 Appendix C MR11.0 Data Management Installation . . . C-1 iv SIB11.0 CONTENTS (cont) Page Introduction . . . . . . . . . . . . . C-1 DM ON A NEW MULTICS SITE . . . . . . . C-1 Preparing to Install DM . . . . . . C-1 Logging in the DM Daemon . . . . . C-2 Multics Configuration Requirements C-2 Creating the DM System Directory . C-2 Creating the system_low Directory . C-2 Creating the DM Configuration Table C-3 Login of the DM Daemon . . . . . . C-3 Existing Multics Site and DM . . . . . C-3 Updating System Tables and Access . C-3 Login of the DM Daemon . . . . . . C-4 Multics Configuration Requirements C-4 Creating the DM System Directory . C-4 Creating the system_low Directory . C-4 Creating the DM configuration table C-5 Login of the DM Daemon . . . . . . C-5 Relationship of AIM and DM . . . . . . C-5 Appendix D Formatting Disks with MTR . . . . . . . . D-1 Formatting MSU0451 Disk Packs . . . . D-1 Formatting MSU0500/MSU0501 Disk Packs D-10 v SIB11.0 ----------------------------------------------------------- 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