MR12.7

From Multics Wiki
Jump to: navigation, search

MR12.7 is the latest release of Multics.

Important Note Regarding Simulator Version

You must be using an R2.0 (or later) version of the dps8m simulator. If you are still using a R1 release of dps8, please upgrade your existing system to R2 first. Instructions for doing so may be found here: http://ringzero.wikidot.com/wiki:release-2-0. The INI files provided as part of the MR12.7 release require at least an R2.0 simulator (the simulator commands and prerequisites changed from R1 to R2. Notably, in R2, you no longer need a Devices.txt or base_system.ini file. In addition, the syntax in the INi file for various aspects of configuration have changed. These are all documented here: http://ringzero.wikidot.com/wiki:release-2-0.

Upgrading an Existing MR12.6 System to MR12.7

There are two ways to upgrade an existing MR12.6 system to MR12.7. The first is by far the simplest way -- by using the MR12.6_to_MR12.7_upgrade.ini simulator script. The second, which more closely mimics the historical way site administrators would upgrade a real hardware-based Multics system, uses a trivial simulator boot script that simply boots the Multics system tape and lets the operator enter all the commands manually. These two procedures are described below.

Note: You can actually upgrade any version of Multics that currently runs directly to MR12.7. You do not need to first upgrade to MR12.6f. Follow the same instructions as for upgrading an MR12.6 system (below).

Upgrading Using the MR12.6_to_MR12.7_upgrade.ini Simulator Script

This process assumes you have a directory populated with an existing, runnable MR12.6 Multics system using an R2.0 (or later) version of the dps8m simulator. The system should be shut down before you start.

  • Make a backup of your whole directory in which you have the Multics system setup (or at least your *.dsk files)
  • Make sure your dps8 (simulator) executable is version R2.0 or later.
  • Make sure you have deleted the files base_system.ini and Devices.txt. These are no longer required with dps8 version R2.0 or later.
  • In the directory with your existing system, add the following files from the MR12.7 distribution:
    • All 5 MR12.7 tapes (see Release Artifacts)
    • The MR12.6_to_MR12.7_upgrade.ini simulator script
    • The MR12.7_boot.ini simulator script
  • Make sure your directory contains:
    • All *.dsk files required to boot your system
  • If you have other logical volumes besides the root logical volume (RLV) in your MR12.6 system, update the MR12.6_to_MR12.7_upgrade.ini script to add each of these logical volumes. The script, as provided, only attaches the root.dsk (RLV) disk as disk0. If you have other disks, add additional lines of the form "attach diskN xxx.dsk" where N is an integer from 1 to 16 and where xxx is the name of the disk file containing your logical volume image.
  • Update the MR12.7_boot.ini to incorporate other custom INI file changes, you require -- for example, if you define slave/autocall channels, you should include them in MR12.7_boot.ini.
  • Change your working directory to your Multics directory.
  • Run "dps8 MR12.6_to_MR12.7_upgrade.ini” (if dps8 isn't on your path, but in your Multics directory, you can use "./dps8 MR12.6_to_MR12.7_upgrade.ini" (Linux or macOS) or ".\dsp8 MR12.6_to_MR12.7_upgrade.ini" (Windows). Otherwise, reference the simulator executable by relative or absolute path.
  • Wait about 20 minutes (more if your system is slow). The simulator script will shut down Multics and return to your command prompt when the upgrade is complete.
  • Note that loading the 12.7LDD_STANDARD tape takes a very long time (due to its containing all the small include segments). Be patient.

When the script exits, you should have a bootable MR12.7 system in your current directory.

Boot your system by running the simulator with MR12.7_boot.ini as the script parameter (e.g. "dps8 MR12.7_boot.ini"). If you have more logical volumes than the root logical volume (RLV) be sure to update the MR12.7_boot.ini script to include disk attachments for those other logical volumes.

Note: If you skipped the step to fix the PDT cutoff dates when you upgraded your system to a prior MR12.6x release, you should follow the instructions in Step 5 of Section 4 in the [Software Installation Bulletin]. This should not normally be required since skipping this step would have rendered it impossible, in your existing system, to login to non-Initializer accounts.

Note 2: The reload_system_release command, used by the upgrade script, creates large map segments in the >reload_dir directory. These are not required for normal system operation. You may delete them in order to conserve disk space. Anyone on the SysAdmin project can delete the map segments, which have names like !BBBKQBlDQKxQzh.reload.map. Alternatively, in admin mode on the operator console, you may delete these map segments with a command such as "dl >reload_dir>**.reload.map".

Upgrading By Hand Using a Minimal Simulator Script

If you want to follow the instructions in the System Installation Bulletin (SIB) and perform an upgrade of a MR12.6 system the way site administrators would have done so in years past, you can following the instructions here.

This process assumes you have a directory populated with an existing, runnable MR12.6 Multics system using an R2.0 (or later) version of the dps8m simulator. The system should be shut down before you start.

  • Make a backup of your whole directory in which you have the Multics system setup (or at least your *.dsk files)
  • In the directory with your existing system, add the following files from the MR12.7 distribution:
    • All 5 MR12.7 tapes (see Release Artifacts)
    • The following (minimal) simulator script saved as "boot.ini":
attach -r tape0 12.7MULTICS.tap
attach disk0 root.dsk
clrautoinput
autoinput \z
boot iom0 
  • Make sure your directory contains:
    • All *.dsk files required to boot your system
  • If you have other logical volumes besides the root logical volume (RLV) in your MR12.6 system, update the boot.ini script to add each of these logical volumes. The above script only attaches the root.dsk (RLV) disk as disk0. If you have other disks, add additional lines of the form "attach diskN xxx.dsk" where N is an integer from 1 to 16 and where xxx is the name of the disk file containing your logical volume image.
  • Update the MR12.7_boot.ini to incorporate other custom INI file changes, you require -- for example, if you define slave/autocall channels, you should include them in MR12.7_boot.ini.
  • Make sure you have a recent copy of the dps8 simulator on your path or in your Multics directory.
  • Change directories to your Multics directory.
  • Follow the instructions in Section 4 of the MR12.7 System Installation Bulletin (SIB), however, you can skip Step 1 (which has you deleting the unbundled directories while booted using your existing system). This is not necessary. Start with Step 2.
  • When you are asked to boot your system, run "dps8 boot.ini” (if dps8 isn't on your path, but in your Multics directory, you can use "./dps8 boot.ini" (Linux or macOS) or ".\dsp8 boot.ini" (Windows). Otherwise, reference the simulator executable by relative or absolute path.
  • Follow all the steps in Section 4.
  • Note that loading the 12.7LDD_STANDARD tape takes a very long time (due to its containing all the small include segments). Be patient.
  • At the end of the instructions in Section 4, you will be left with a running MR12.7 system.

When you shut your system down, you can boot it again using the same minimal boot.ini (but be prepared to manually enter all the pre-bce and bce commands required to bring your system up). Alternatively, boot your system by running the simulator with MR12.7_boot.ini as the script parameter (e.g. "dps8 MR12.7_boot.ini"). If you have more logical volumes than the root logical volume (RLV) be sure to update the MR12.7_boot.ini script to include disk attachments for those other logical volumes.

Note: The reload_system_release command, used by the upgrade script, creates large map segments in the >reload_dir directory. These are not required for normal system operation. You may delete them in order to conserve disk space. Anyone on the SysAdmin project can delete the map segments, which have names like !BBBKQBlDQKxQzh.reload.map. Alternatively, in admin mode on the operator console, you may delete these map segments with a command such as "dl >reload_dir>**.reload.map".

Installing MR12.7 as a New System (QuickStart)

If you just want to bring up a brand new MR12.7 to play with it, use the QuickStart. Here are instructions for using it:

  • Download and unzip the QuickStart, found here: MR12.7 QuickStart
  • Download or build an simulator for your platform. See http://ringzero.wikidot.com/wiki:release-2-0 for details.
  • Drop the "dps8" executable into your QuickStart folder
  • Run "./dps8 MR12.7_boot.ini" (Linux or macOS) or ".\dps8 MR12.7_boot.ini" (Windows)
  • Once booted, use another terminal window to telnet to Multics ("telnet localhost 6180" on Linux and macOS; for Windows, use putty or equivalent)

Cold Booting a New MR12.7 System from Scratch

You have three options if you'd like to create a fresh MR12.7 Multics system. You can use the QuickStart (see previous section), or you can perform a Multics cold boot yourself. There are two ways to perform the cold boot. The first, and easiest option, is to use the Script to cold boot MR12.7. (This is how the QuickStart was created). The second, is to manually install Multics using the instructions in the MR12.7 System Installation Bulletin. This second option is what site administrators would have done back in the days of Multics hardware-based implementations. It provides an near-authentic experience and allows maximum customization. Because all commands must be entered manually, it is more error prone, time consuming, and most likely frustrating. It is presented here because it more closely matches historical cold boots.

Cold Booting a New MR12.7 System Using the MR12.7_coldboot.ini Simulator Script

  • Create an new directory
  • In this directory, add the following files from the MR12.7 distribution:
    • All 5 MR12.7 tapes (see Release Artifacts)
    • The MR12.7_coldboot.ini simulator script
    • The MR12.7_boot.ini simulator script
  • Make sure you have a recent copy of the dps8 simulator on your path or in your Multics directory.
  • Change directories to your Multics directory.
  • Run "dps8 MR12.7_coldboot.ini” (if dps8 isn't on your path, but in your Multics directory, you can use "./dps8 MR12.7_coldboot.ini" (Linux or macOS) or ".\dsp8 MR12.6f_coldboot.ini" (Windows). Otherwise, reference the simulator executable by relative or absolute path.
  • Note that loading the 12.7LDD_STANDARD tape takes a very long time (due to its containing all the small include segments). Be patient.

When the script exits, you should have a bootable MR12.7 system in your current directory.

Boot your system by running the simulator with MR12.7_boot.ini as the script parameter (e.g. "dps8 MR12.7_boot.ini"). If you have more logical volumes than the root logical volume (RLV) be sure to update the MR12.7_boot.ini script to include disk attachments for those other logical volumes.

Note: The reload_system_release command, used by the coldboot script, creates large map segments in the >reload_dir directory. These are not required for normal system operation. You may delete them in order to conserve disk space. Anyone on the SysAdmin project can delete the map segments, which have names like !BBBKQBlDQKxQzh.reload.map. Alternatively, in admin mode on the operator console, you may delete these map segments with a command such as "dl >reload_dir>**.reload.map".

Cold Booting a New MR12.7 System Manually

If you want to follow the instructions in the System Installation Bulletin (SIB) and perform an cold boot of a MR12.7 system the way site administrators would have done so in years past, you can following the instructions here.

  • Create an new directory
  • In this directory, add the following files from the MR12.7 distribution:
    • All 5 MR12.7 tapes (see Release Artifacts)
    • The following (minimal) simulator script saved as "boot.ini":
attach -r tape0 12.7MULTICS.tap
attach disk0 root.dsk
clrautoinput
autoinput \z
boot iom0 
    • The MR12.7_boot.ini simulator script
  • Make sure you have a recent copy of the dps8 simulator on your path or in your Multics directory.
  • Change directories to your Multics directory.
  • Follow the instructions in Section 5 of the MR12.7 System Installation Bulletin (SIB).
  • When you are asked to boot your system, run "dps8 boot.ini” (if dps8 isn't on your path, but in your Multics directory, you can use "./dps8 boot.ini" (Linux or macOS) or ".\dsp8 boot.ini" (Windows). Otherwise, reference the simulator executable by relative or absolute path.
  • Follow all the steps in Section 5.
  • Note that loading the 12.7LDD_STANDARD tape takes a very long time (due to its containing all the small include segments). Be patient.
  • At the end of the instructions in Section 5, you will be left with a running MR12.7 system.

When you shut your system down, you can boot it again using the same minimal boot.ini (but be prepared to manually enter all the pre-bce and bce commands required to bring your system up). Alternatively, boot your system by running the simulator with MR12.7_boot.ini as the script parameter (e.g. "dps8 MR12.7_boot.ini"). If you have more logical volumes than the root logical volume (RLV) be sure to update the MR12.7_boot.ini script to include disk attachments for those other logical volumes.

Note: The reload_system_release command, used in the above steps, creates large map segments in the >reload_dir directory. These are not required for normal system operation. You may delete them in order to conserve disk space. Anyone on the SysAdmin project can delete the map segments, which have names like !BBBKQBlDQKxQzh.reload.map. Alternatively, in admin mode on the operator console, you may delete these map segments with a command such as "dl >reload_dir>**.reload.map".

Release Artifacts

Here are some links to relevant MR12.7 artifacts:

  • Single ZIP file with MR12.7 Release Tapes, SRB, SIB, system book, and simulator INI files:
  • Listings Tape (hardcore listings)
    • MR12.7 Hardcore Listings Tape
      • Note: If you extract this tape onto a Multics system, the listing segments will be reloaded to the >ldd>listings directory. You will need about 30500 records of disk space/quota in order to load this tape. Please make sure you have enough disk space on the logical volume (LV) where your >ldd directory exists, or consider precreating the >ldd>listings directory on another LV. Alternatively, you can use a control file to direct the segments to be reloaded into a different directory.

Most Important New Features of MR12.7

Volume Pool Support for Hierarchy Backup

The Volume Backup support has long allowed tapes to be allocated from a volume pool, however up until this release, this support was not extended to the Hierarchy Backup daemons. If a volume pool is setup and configured for the incremental, catchup, or complete backup daemons, tapes will be allocated from the configured pool. A single pool can be used, or separate pools per backup type can be employed.

See the info segments for the backup_dump, start_dump, catchup_dump, and complete_dump commands for more info on using volume pools with the hierarchy backup commands. See also the updated documentation on these commands in the Multics Administration, Maintenance, and Operations Commands (GB64) manual errata -- gb64.errata.info.

History Comments Now Allowed in Info Segments

Prior to this release, it wasn't possible to include history comments to track changes in info segments. Now with an updated version of the history_comment (hcom) command, you can. See the instructions for adding history comments in info segments by issuing the command "help info_seg.hcom".

mbuild

A new subsystem, mbuild, has been introduced that helps developers prepare additions to the software libraries, or changes to software in those libraries. This system helps with compilation, source/object archive updating, binding, checking history comments, performing source comparisons, and installing changes to the system libraries.

The mbuild subsystem also helps system and library administrators manage installations into the system libraries.

verify_info, info_seg_, and help_

The validate_info_seg command has been replaced with the verify_info command. The help_ subroutine now uses a new info_seg_ subroutine to parse info segments, and provides a more powerful user interface for displaying that information.

56 Tickets Resolved

There were 56 tickets (see: https://multics-trac.swenson.org/, and if you don't have an account there, use "anonymous" as the username and "multics" as the password when it asks for same) fixed in this release. See the Software Release Bulletin] for details.