<REFERENCE>PRIME>DRB>INSTALLOVIEW
About this page
This document is an overview of what is involved in doing a custom install of PRIMOS and layered products from scratch. The object is not to give specific instructions, but rather to summarize the tasks involved, explain a little bit about what's going on, and provide pointers to documentation.
If you just want to follow a recipe, this isn't the 'droid you're looking for. You may find the sample machine images for Jim's emulator helpful. There is also a growing collection of version-specific install howtos on the drb reference material page.
Prime documentation
Each release had some form of release documentation that discussed how to install it, significant differences from past releases, etc. Relatively little of that documentation has survived, most of it in the form of changes information.
What exists may be found here:
It's well worth reading the Rev. 22 guide even if you're working with a different version of PRIMOS, so that you've seen how Prime expected this to be done.
The System Administrator and Operator guides which are referred to generically below may be found here:
Plan
Before starting to recycle actual bits, you should probably examine the available (virtual?) hardware resources. Key decisions that would have been made for real hardware systems include understanding how much paging space would be required, what the i/o load would have looked like and how to spread it across spindles to improve performance, etc. For emulator use, it's likely that you can easily afford the host disk space to have several of the largest supported disk types. Host disk performance is likely many times that of the original hardware, so it is less critical to plan for distribution across spindles.
On the Prime, disks are partitioned by selecting the number of heads to use, whereas with modern OSes, you select the number of cylinders to use. The heads must be contiguous, and must start on an even numbered head. Though SCSI drives in Prime systems are accessed via logical block address in hardware, the software still treats them as cylinder / head / sector devices, hallucinating a mapping which the disk controller also knows about.
You'll need at least a command device and a paging device. Paging devices can be "split" starting around Rev. 19, so that you can have a BADSPT (list of error sectors) file. Plan to split your paging disk(s), as later revisions complain if they're not, and it makes it easier to identify the partitions later. You can tell MAKE, when it asks for split sizing to use "MAX".
Work out the pdev (physical device) numbers for your disks using either the tables, or via the bit maps. These helps are in the System Operator guides. Pdev numbers are bit maps which select controller, drive on that controller, starting head number and head count, and are specified in octal.
Prepare your disks
Having decided what your disk layout should be, you now need to prepare your partitions for use. In the emulator, you'll want to create empty host files with appropriate names, e.g. using the touch command. For real hardware, you would make sure everything is cabled up, powered up, spinning, etc.
To create the partitions, you boot the MAKE program from tape once for each partition. (In the emulator, you can actually boot MAKE from a host file if you have an extracted copy handy.) Before about Rev. 22, the tape bootstrap record reads MAKE directly from the tape into memory. Starting at Rev. 22, you actually start a barebones version of PRIMOS, then use the MTRESUME command to load MAKE.
When started from tape like this, MAKE immediately prompts for options. The length of the string you can type in here is a bit limited, so note that you can specify just the -options, and it will then prompt for the values that go with those options.
The available options (and their acceptable abbreviations) changed a bit over time, so you'll need to review manuals of the appropriate era, or use the built-in help by starting MAKE with the -help option. MAKE and partitioning in general are documented in the System Operator manuals.
For emulator disks, it's not necessary to do the format or badspot checking operations, and skipping them will reduce the amount of disk space used until the disk actually fills up substantially, and MAKE will take a lot less time to complete. On real hardware, if you're not using SCSI disk, you will need to do both, and the process can take hours.
Restore tapes
Real Prime distribution tape sets included a series of logical saves spanned across multiple tape reels or cartridges. The saves are named somewhat cryptically, with the name consisting of the letter 'M', three digits representing the version of PRIMOS (e.g. 21.0.6 would be represented as 210), and two additional letters and digits. The logical saves which might appear include, in order:
- BT boot tape (contains MAKE, MAGRST, DOS or skeleton PRIMOS)
- U1 Base operating system
- U2 Optional additional files for the base operating system
- V1 Source code for the base operating system
- C1 Chargable layered products
- D1 Source code for chargeable layered products
- IC Other layered products
Not all of these will be included in every tape set - some were not introduced until later releases of PRIMOS, few sites had all sources or layered products, etc. In later releases, one final save was included, called KLMTF. It contains template files for serialization, which can be used to re-serialize software after it is rebuilt from source.
On the emulator, you can probably just restore all of these, then sort things out from there. On real hardware where disk isn't free, you may have to pick and choose, restore some things onto partitions other than the command device, or do things in stages. You'll restore BT and U1 onto the command device. U2, if present, is optional, but note that it contains the HELP files. Source code can go anywhere it fits, and is not required unless you want to peruse it or modify / build from it. Chargeable products can be restored anywhere, and then their installs will copy them onto the command device. A few may support placing some parts on disks other than the command device. Nearly any product-specific directory may be moved to a disk other than the command device.
The tapes are read by booting MAGRST, or booting the skeleton PRIMOS and using MTRESUME to fetch MAGRST.
Set up search rules
On Rev. 19.4 and later, PRIMOS has a set of search rules which are used to control the order in which the system seeks commands, UFDs, subroutines, etc. Many things don't work very well until these are set up. You should reboot after doing this, so that the new SR configuration is active, before continuing.
Create SAD and add users
Starting at Rev. 19, the system authorization database needs to be created. This is done (and the SAD is later maintained) using the EDIT_PROFILE command. The prompts changed some from version to version. Check the System Administrator guides for details.
You will see errors about the missing SAD at boot time, until it is created. At later releases, the system will not allow users to log in on serial lines until the SAD exists.
Configure
A configuration file contains boot-time settings for the PRIMOS kernel. It is usually CMDNC0>CONFIG, though that's not required. Directives in this file set the count and size of various buffers, limit the number of terminal, phantom (background process) and other types of users, select the default erase and kill characters, etc. Details are in the System Administrator guides.
Commands that should be run at boot time are placed in CMDNC0>PRIMOS.COMI. This is where partitions other than the comdev are started up using the ADDISK command, libraries are shared using the SHARE command, serial lines are configured using the AMLC command, the spooler, batch queue monitor and other system background jobs may be started, etc. A sample PRIMOS.COMI may be found in PRIRUN. An older name for this file is C_PRMO. The first non-comment command in PRIMOS.COMI must be CONFIG. If you have used the standard name for the config file, then this command will be CONFIG -DATA CONFIG.
In many cases, PRIMOS.COMI invokes subordinate COMI files to do some of this work. For example, most shared libraries and products each have a COMI file.
It is also common to have a CMDNC0>AMLC.COMI which does the serial line setup. For versions before about Rev. 22, the AMLC command is the mechanism for configuring lines. Starting at Rev. 22, while AMLC isn't gone, the SET_ASYNC and CAB commands are the preferred ones. See the System Administrator guides for details.
Things that need to be shared on nearly every version include the system line editor ED, and the system FORTRAN libraries. Nearly all compilers, data management software, and networking software have shared components.
It may be useful, in doing this setup, to know a little bit about file units and the cominput mechanism. PRIMOS is able to switch the source for commands to a file. This is done using the COMINPUT (abbreviated CO) command. When a file is opened, it is assigned a file unit, which has a small integer number, and is associated with the system tables that keep track of such things. The standard file unit for cominput files is 6. If desired, one can give a file unit number on the COMINPUT command to indicate that a different unit should be used. It is common to invoke subordinate command files from PRIMOS.COMI (which is open on unit 6) on unit 7. For example, you may see CO AMLC.COMI 7. At the end of each such subordinate file, you will usually see CO -CONTINUE 6 to resume taking input from PRIMOS.COMI.
The only editor that will work before you have the shares working is the non-shared line editor. See the New User's Guide to Editor and Runoff to learn how to use the line editor.
Install layered products
Each layered product is distributed in its own UFD. All have an install script, usually .CPL, but sometimes .COMI, to create needed directories, copy files into place, adjust ACLs and search rules, etc. You will attach to the distribution UFD and invoke the install script, using the RESUME or CPL commands for .CPL scripts, or the COMINPUT command for .COMIs.
Some products may have requirements for settings in CONFIG which will be your responsibility. Many have components which need to be shared, and will include a share .COMI in SYSTEM which you will need to call from PRIMOS.COMI.
The product manuals rarely discuss installation. The PRIMOS install guides cover basic layered product installation. Product directories may include readmes with clues or instructions. In many cases the basic install is as simple as described above.