-*- Text -*- This is the file AI:KSHACK;BUILD DOC Building a new KS10 ITS from scratch 1. Inventory Your KS10 ITS distribution kit includes: 1. A KS10 boot tape containing the Salvager (labeled "Salvager"). 2. A KS10 boot tape containing DSKDMP (labeled "DSKDMP"). 3. A DUMP tape containing the minimal files needed to bring ITS up for the first time (labeled "MINSYS"). 4. Four DUMP tapes containing sources and binaries for ITS itself, and various programs including EMACS and MacLisp (Labeled "Distribution tape #..."). 5. Hardcopy of the files: KSHACK;BUILD DOC KSHACK;CONSOL > KSHACK;DSKDMP ORDER KSHACK;AINOTE > KSHACK;KSDEFS > SYSDOC;DUMP FORMAT .INFO.;DUMP INFO 2. General explanations This document contains step-by-step instructions for building a new ITS system for a KS10. This section introduces the major players. The following sections describe the steps in detail. We use "$" to indicate the altmode/escape character (ascii code 33 octal). Control characters are indicated by a proceeding "^", so "^Z" indicates the character Control-Z (ascii code 32 octal). "" is used to indicate the carriage return character (ascii code 15 octal). In this document we use a trailing "." to indicate a decimal number. All other numbers are in octal. (Thus "105" and "69." both denote the same number.) However, when these instructions tell you to "type a decimal number" it only means that the sequence of digits you type will be interpreted as a decimal number. It does not mean that you need to employ any special notation to indicate the radix (such as a trailing decimal point), in fact, you must not. 2.1. The 8080 front end The 8080 front end processor serves as a front console for the KS10. It can be used to start and stop the machine, examine and deposit memory, load and debug both machine language and microcode, as well as boot the KS10 from tape and disk. The 8080 also controls the system console. Under normal operations the 8080 simply passes characters between the processor and the system console, however typing ^\ causes the 8080 to enter command mode. When the machine is initially powered on, the 8080 is already in command mode. Command mode is indicated by the prompt: KS10> The 8080 will leave command mode if you type ^Z. Relevant commands are: MT Loads the machine from a KS10 boot tape. (Boot tapes are explained below.) BT Loads the machine from the front end filesystem on the disk. (Part of the process described in this document is how one installs a front end filesystem.) ST nn Starts the machine at address nn. HA Halts the machine. A wallchart of the most useful 8080 front end commands can be found in the file KSHACK;CONSOL >, there are many many more documented in the DEC manuals. 2.2. Tape formats There are two different tape formats used on the tapes in your distribution kit. A "KS10 boot tape" is used to load a standalone program into the KS10 directly from tape. The MT command to the 8080 front end causes it to load a KS10 boot tape. Such a tape starts with several records of microcode that the 8080 loads into the KS10 micromachine. This is followed by a bootstrap program, called "MTBOOT", that the 8080 loads into main memory and starts. MTBOOT reads an Exec DDT and some other program into memory from the rest of the tape and starts DDT. [Footnote: We do not use the DEC standard microcode. The most important differences are that the ITS microcode supports ITS-style paging and has a different set of I/O instructions. The file KSHACK;KSDEFS > documents the ITS microcode.] A "DUMP tape" contains files (and links) in the format produced by the ITS DUMP program. It can be used to load files into the filesystem either using the TRAN routine in the standalone Salvager or using the DUMP program running under timesharing. The file SYSDOC;DUMP FORMAT describes the format of DUMP tapes. The two kinds of tape are not in the slightest way compatible with each other. 2.3. Exec DDT There are perhaps more versions of DDT in the world than there are species of insect. The standalone DDT used by ITS (sometimes called "Exec DDT") is incompatible with every other DDT, including the DDT used on ITS under timesharing. It's not documented anywhere, but the usual commands ($G, /, return, etc.) work in the usual ways. Exec DDT has very primitive rubout processing. Typing a rubout/delete will cause it to completely abort all unprocessed characters. When Exec DDT is loaded its start address is 774000. Even under timesharing, Exec DDT is always kept at that location. Thus you can usually get to DDT by starting the KS10 at that address (using the ST command to the 8080 front end). 2.4. The Salvager The Salvager is a program that runs standalone and performs various filesystem maintenance operations. It knows how to format disk packs and how to copy them, how to build filesystems, how to detect damage in a filesystem, and it contains tools that enable a hacker to repair a damaged filesystem. Documentation for the Salvager can be found in its source. The Salvager used on the KS10 is a rewrite of the older salvager still used for the KA10 and the KL10, its source can be found in the file KSHACK;NSALV >. Routines in the Salvager are run by simply using DDT to start them. Thus to run the Salvager routine "CHKR", one types (to Exec DDT): CHKR$G Relevant routines in the Salvager are: MARK Formats a disk pack. TRAN Reads files from a DUMP tape and writes them into the filesystem. CHKR Checks the filesystem for problems. FESET Sets the pointer on disk used by the 8080 front end to boot the machine. Examples of using all of these routines appear in the following sections. Salvager routines prompt for and process input in a variety of idiosyncratic and inconsistent ways. Sometimes numbers are read in decimal, sometimes they are read in octal. Sometimes (for example when asking for the number of a disk drive) only a single digit is read, and any additional input you accidentally type, such as a carriage return, will be taken as a response to the following command. In the instructions that follow, I have tried to carefully specify exactly what you must type, and how it will be interpreted. You should be equally careful about following these instructions. When a Salvager routine is finished it will generally type: DDT and return you to Exec DDT. Serious errors will also cause Salvager routines to print an error message and return to DDT. Whenever the Salvager is waiting for input, typing ^Z will abort and return immediately to DDT. Remember this. It will come in useful the first time you make a error while typing to a Salvager routine. (The Salvager's rubout processing is generally pretty poor.) A copy of the Salvager is also merged in with a dumped out ITS. This is so that before ITS starts running it can call the Salvager to check out the filesystem (performing the same checks as CHKR). 2.5. DSKDMP DSKDMP is a sort of miniature disk operating system. It is used to load programs from the ITS filesystem into memory and start them, and to dump memory into the filesystem. The DSKDMP program itself is kept on disk in the extra cylinders that are beyond those used by the filesystem. DSKDMP also uses this area of the disk for swapping space. A short DSKDMP bootstrap program is always kept in the last 64. words of memory, from 777700 through 777777, even when timesharing is running. This bootstrap knows how to find DSKDMP on disk and swap it in, swapping out whatever is currently in main memory. Thus once DSKDMP is installed you can usually (unless something trashes those 64. words) start it up by starting the KS10 at address 777700 (using the ST command to the 8080 front end). The $U command in Exec DDT will check to see if the DSKDMP bootstrap is present, and will jump to it if it is. This is the most common way of starting DSKDMP. When the 8080 front end filesystem has been built as described below, the BT command to the 8080 (or pressing the BOOT switch) will load the DSKDMP bootstrap into memory and start it. This makes it possible to get a DSKDMP no matter what main memory contains (for example, after powering on the machine). DSKDMP commands are either simply the name of a file to load and start, or a single letter followed by an altmode. Many single letter commands are then followed by a filename argument. Relevant DSKDMP commands are: F$ Lists the current directory. L$file Loads the file into memory without starting it. T$file Loads the file into memory assuming Exec DDT is already loaded. Gives the file's symbols to DDT and starts DDT. M$file Merges the file into memory. Does not load symbols or start anything. D$file Dumps memory into the named file. Examples of using all of these commands appear in the following sections. DSKDMP has an unusual convention for reading filenames: if only a single name is given, then that is taken to be the second name of the file, and the first name is defaulted to "@". Thus when giving DSKDMP a filename ".;ITS" refers to the file .;@ ITS. DSKDMP commands that read and write files sometimes take a few seconds to run. So that you will know when DSKDMP is done executing a command, DSKDMP will not type a linefeed until after the command is finished. DSKDMP has very primitive rubout processing. Typing a rubout/delete will simply cause it to start over and prompt for a new command. DSKDMP error messages are somewhat terse. A wallchart of DSKDMP commands and error messages can be found in the file KSHACK;DSKDMP ORDER. 3. Formatting the disk Mount the Salvager boot tape and give the MT command to the 8080. (Type ^\ to get the 8080 into command mode if necessary.) This will load the Salvager and Exec DDT into the KS10 and start DDT. MTBOOT announces itself: ITS MTBOOT.176 If something goes wrong while reading the tape, MTBOOT will try and tell you about it, otherwise when the tape stops spinning, MTBOOT is finished and has started Exec DDT. (A common error here is to forget to put the tape drive on line.) Mount a disk pack on a drive. Understand that you are about to lose any information you had on that pack. Check that the drive is not write protected. Just to be safe, you should probably write protect any other drives you happen to have. Run the MARK routine the in Salvager: MARK$G The Salvager will begin by asking you: Format pack on unit # You should respond by typing the number of the drive in question. Do not type a carriage return after typing the number, the Salvager is only waiting for you to type a single digit. The Salvager now asks: Are you sure you want to format the pack on drive # 0 (Y or N) You should respond by typing "y" if this really is what you want to do. Do not type a carriage return, the Salvager is only waiting for you to type a single character. It will then ask you: Pack no ? The disk packs in an ITS filesystem are numbered. Pack numbers can be anywhere from 0 to 31., and are customarily written in decimal. It is customary for the first pack to be number 0, although this isn't necessary. With this question the Salvager is asking you what number you want this pack to be, answer by typing a decimal number (between 0 and 31.) terminated by a carriage return. The Salvager will type something like: Pack 0., Drive #0 is serial #2184. Begin formatting 815. cylinders.... and will start formatting the pack. This will take several minutes (about 10. for an RP06), go make yourself a cup of tea while you wait. When the formatting is finished the Salvager will type: Hardware formatting complete. Verify pack? (Y or N) The Salvager is offering to check that the pack is OK by reading back everything it has just written. Unless you like to live very dangerously, you should answer "y". Do not type a carriage return, the Salvager is only waiting for you to type a single character. There are likely to be ECC correctable errors detected during this verification phase. For each such error the Salvager will tell you where the error occurred by typing something like: Disk transfer error on unit 0. ECC Corrected error: Unit #0 Cylinder 1264 Head 12 Sector 20 After verification is finished (it takes just as long as the writing phase), the Salvager will count the number of ECC correctable errors that occurred: 7 ECC-corrected errors during verification. An absurdly large number of ECC errors, or some other error occurring during verification should make you start over with a better disk pack. The Salvager now asks you for the amount of swap space you want to allocate on this pack for ITS to use: Swapping Alloc? This number (given in octal), is the number of blocks that ITS should avoid using for file storage at the front of the pack. This assures that there will always be some empty space on the disk for swapping. Since ITS will use any free block on the disk for swapping, not just those in the swapping area, this is really only the minimum amount of swapping space. However, since the first 500. blocks of the disk are already committed for storing directories and the "HOM blocks" (part of the front end filesystem), you will actually get 500. blocks less guaranteed swapping space than the number you type here. If you find this all confusing, just type "3000". This gives you a minimum of 1036. blocks of swapping space. Now the Salvager asks: Pack #0. ID? The Salvager wants you to tell it the name of the physical disk pack. This is whatever is actually written on the pack's physical label (probably a little piece of paper glued to the cover). (This "pack ID" is different from the pack number, because in the future you might copy the contents of this pack to a fresh disk pack. That new pack would still be pack #0 in the filesystem, but would have something different written on its label. The pack number is the name of the information written on the pack, and the pack ID as the name of the physical pack itself.) You should type a string of up to six characters followed by a carriage return. The MARK routine is now finished formatting the pack, and it returns you to DDT after typing: DDT 4. Loading the minimal files The filesystem you just built is completely empty, so the next step is to load a minimal set of files into the filesystem so that you can bring ITS up for the first time. Mount the minimal filesystem tape (the one marked "MINSYS") on the tape drive, and run the TRAN routine in the Salvager: TRAN$G The Salvager asks: onto unit # You should respond by typing the number of the drive where your ITS pack is mounted. As before, you should not type a carriage return after the unit number, since the salvager is only waiting for you to type a single digit. As usual, the Salvager wants to make sure you know what you are doing, so it asks: Copy from unit #5 onto unit #0, OK (Y or N) By "unit #5" it means "the tape drive". This does not mean that it is going to address the tape drive as drive number 5. The Salvager always uses tape drive number 0. The digit "5" has absolutely no significance, "unit #5" is just the Salvager's name for the tape drive. You should respond by typing a "y" if the target unit number is correct. The Salvager now types: Tape #1 .;@ DDT This means that header on the tape you have mounted identifies this tape as being tape #1, and that the first file on the tape is the file .;@ DDT, which the Salvager is now loading. When the file has been loaded, the Salvager types "OK" and proceeds to the next file: .;@ DDT OK .;ITS BIN This process should continue for about 60. files until the end of the tape, at which point the Salvager types: EOT DDT and returns you to DDT. 5. Checking your new filesystem At this point you might want to satisfy yourself that there really is a good filesystem out there. The CHKR routine in the Salvager is the principal means for checking the consistency of the filesystem. To run it type: CHKR$G Since this routine is the Salvager's most common function, the Salvager starts by announcing itself: Salvager 215 before asking you: Active unit numbers? To answer this question the Salvager wants you to type a sequence of digits, each representing the number of an active disk drive in your filesystem. Since at this point you only have a single drive, you should just type its number, followed by a carriage return. The Salvager will now inform you about which packs are mounted on the drives you have specified: Unit #0. ID is PM001, Pack #0 The unit number, pack ID, and pack number should all look familiar to you. Now the Salvager asks: Use MFD from unit: The ITS filesystem keeps duplicate copies of all directories on all packs for safety. Here the Salvager is asking you which copy of the Master File Directory (the catalog of all the user directories) you regard as authoritative. If you were recovering from some accident to a multi-pack filesystem, this would be a useful question. Since you only have a single drive, just type the drive number again (and don't type a carriage return). Now the Salvager asks: Read all blocks of all files? (Y or N) The Salvager is offering to test the readability of every file in your filesystem. When you have more files in the filesystem, this will be quite a slow operation, but at this point it won't delay things too much, so you might as well type "y". Get user dirs from unit: Now the Salvager wonders which drive has the pack you regard as authoritative for the user directories. Again, since you only have a single pack, you can only answer by typing the number of its drive (and no carriage return). Now the Salvager starts working. It is highly unlikely that there will be any problem detected. There is a possibility of some ECC correctable errors during this process, but these aren't fatal. If all is well the Salvager simply returns you to DDT after typing (as usual): DDT 6. Installing DSKDMP Now that you have a filesystem you need to install DSKDMP on your pack. Start by mounting the DSKDMP boot tape and giving the MT command to the 8080. (Type ^\ to get the 8080 into command mode if necessary.) This will load an Exec DDT and a program for installing DSKDMP into the machine. As usual MTBOOT types: ITS MTBOOT.176 when it starts running, and leaves you in DDT after it has read the tape. To go ahead and install a DSKDMP on disk, you have to actually run the program that was just loaded, so type: $G This writes a copy of DSKDMP on your disk, installs the DSKDMP bootstrap in memory, and starts DSKDMP running. DSKDMP announces itself: DSKDMP To check that all is well, you can start by listing the directory named "." where non-timesharing binary programs, like ITS itself, are generally stored. To do this, use the F$ command to DSKDMP: F$ DSKDMP should show you a listing like this: #00 RAM RAM #00 BT BIN #00 DSKDMP BIN #00 SALV BIN #00 ITS BIN #00 @ DDT where "#00" is the pack number of your single pack. We will see what each of these files is for in the following sections. 7. Dumping an ITS Now it is time to dump out an executable binary for ITS. Start by using the L$ command to DSKDMP to load (but not start) a copy of Exec DDT by typing: L$DDT This loads the file .;@ DDT into your machine. Now use the T$ command to load .;ITS BIN into memory, give its symbols to Exec DDT, and start DDT, by typing: T$ITS BIN Since DSKDMP has started DDT running, you can take this opportunity to use DDT to patch ITS in any way that might be appropriate. It's is unlikely that you know of any such patches under the circumstances, so use the $U command to DDT to return to DSKDMP by typing: $U which should cause DSKDMP to return and announce itself: DSKDMP Now use the M$ command to DSKDMP to merge the file .;SALV BIN into the programs already in memory by typing: M$SALV BIN Finally, dump the whole mess out by typing: D$ITS which will dump memory into the file .;@ ITS. If you give the F$ command now by typing: F$ DSKDMP should show you a directory like this: #00 @ ITS #00 RAM RAM #00 BT BIN #00 DSKDMP BIN #00 SALV BIN #00 ITS BIN #00 @ DDT 8. Bringing up ITS for the first time Now you are ready to run timesharing for the first time. The installation procedure is not yet finished, because you have not yet built a front end filesystem. However the program for manipulating the front end filesystem only runs under timesharing. You should still be talking to DSKDMP after having dumped out an executable ITS binary. To load that binary, and start it in Exec DDT, you need only type the name of the file to DSKDMP: ITS After DSKDMP is finished (indicated by typing a linefeed), tell DDT to start ITS by typing: $G ITS starts by calling the Salvager, which starts by announcing itself: Salvager 215 The Salvager will not ask you any questions this time. It will make some reasonable assumptions about what you want done, and will return to ITS after it is finished. (It exits to DDT if there are problems with the filesystem. "GO$G" will start ITS without running the Salvager, should you be in foolish desperation.) ITS now initializes itself. ITS will discover that it does not know the time, so it will complain: THE KS-10 CLOCK HAS BEEN RESET, IF THE TIME CANNOT BE DETERMINED FROM THE NETWORK, YOU MAY HAVE TO :PDSET YEAR, PDTIME OFFSET, NOT ON DISK. PLEASE SETLOC APPROPRIATELY. One of the things you will do when timesharing starts is learn how to set the time. When ITS finally starts running the system console will type: PM ITS 1585 SYSTEM JOB USING THIS CONSOLE. LOGIN TARAKA 0 TARAKA DMPCPY . _DMPCP OUTPUT WRITE TARAKA DMPCPY . @ ITS DELRNM The first line tells you what version of ITS is running, what machine (PM) it was assembled for, and that this terminal is currently functioning as the system console. The second line tells you that someone with user name "TARAKA" has logged in. TARAKA is the system demon charged with starting all other system demons. One of the demons TARAKA will start is named DMPCPY. The next two lines show the job named "TARAKA DMPCPY" copying the file .;@ ITS. (ITS logs all file operations in system directories on the system console.) It is beyond the scope of this document to explain why DMPCPY is copying this file. Now you are ready to log in. Type ^Z. After a moment ITS should respond: PM ITS.1585. DDT.1513. TTY 0 You're all alone, Fair share = 75% (ITS does not know the date, so messages cannot be reviewed right now.) 8.1. Setting the time using PDSET You are now talking to timesharing DDT, a program you will get to know much better as you learn more about using ITS as a user. At this point all you need to know is that you run a program by typing a ":", the name of the program, and then a carriage return. You want to begin by telling the system what the time is. So run the PDSET program by typing: :PDSET You will then see: (Please Log In) ___002 PDSET IOTLSR PDSET.113 Please don't use this program unless you know how. You are certain to break something if you happen to hit the wrong key. Type Control-Z to exit, or ? for a reminder of the commands. The reminder to log in (first line) was typed by timesharing DDT, which wants to discourage you from running programs before you tell the system who you are. For the moment you can ignore it since your machine doesn't have a reasonable database of user names yet anyway. The second line was typed by ITS on the system console to advertise the fact that the job named "___002 PDSET" is going into User I/O mode (see the processor manual if you don't know what that is). This message isn't actually part of your output at all, its only because you have chosen to log in from the system console that causes you to see this message. "___002 PDSET" is the name of the job that timesharing DDT has created for you to run the PDSET program in. The rest of this output is coming from the PDSET program itself. It tries to scare you away from using it because normally you don't want people randomly playing with the system's clock. At this point you can type "?" to see a list of the available commands if you like. All you need to type is: yymmddD where the current year is 19yy, and this is the dd'th day of the mm'th month. Then type: hhmmssT where the current time is hh:mm:ss in 24-hour time. And then type: !. (That's right, an exclamation point followed by a period.) The instant you type the "." will be taken to be the time you have specified with the D and T commands. At this point the system will type on the system console something like: 114562/ 0 773322,,1757 ___002 114561/ 0 3702 ___002 IT IS NOW 9:05:06 PM EDT, TUESDAY, APR 29,1986 These messages indicate that PDSET has persuaded ITS about the current date and time. To exit PDSET type: Q and you will be back at timesharing DDT. 8.2. Building a front end filesystem using KSFEDR Now run the KSFEDR program to build the front end filesystem. To DDT type: :KSFEDR DDT will remind you: (Please Log In) and then run KSFEDR, which will start by looking for the front end filesystem. It won't find one, of course, so it will say: ERROR: File not found: PK0000: .; .FEFS. PK0000 ! (If you choose a pack number other than 0 when you formatted the disk, you will see a different filename here.) You should cause KSFEDR to create a fresh front end filesystem by typing: create ITS will now type on the system console something like: ___002 KSFEDR . .FEFS. PK0000 WRITE 21:06:01 which indicates that the job ___002 KSFEDR has written a file named .;.FEFS. PK0000, at the indicated time. (All messages on the system console include the time of day once the system knows what that is.) KSFEDR now informs you of what it has done: FE filesystem DSK: .; .FEFS. PK0000 on pack #0. Directory address: 6000000004 ! Remember that directory address! You will need to remember that number later so that you can give it to the FESET routine in the Salvager and complete the process of installing the front end filesystem. Make sure you get it right, it tends to have a lot of zeros in the middle which makes it hard to remember. Now you need to put two files in the front end filesystem. Tell KSFEDR that you want to write a file by typing: write It responds: Are you sure you want to scribble in the FE filesystem? You type: yes It asks: Which file? You say: ram because you want to write the microcode file. It says: Input from (Default DSK: USERS3; RAM RAM): which is almost right, you actually want the file DSK: .; RAM RAM, so you type .; and the microcode is written. Next you want to write the DSKDMP bootstrap, so again you say: write It responds: Are you sure you want to scribble in the FE filesystem? Again you type: yes When it asks: Which file? This time you say: bt And it offers Input from (Default DSK: USERS3; BT BIN): which is almost right, you actually want DSK: .; BT BIN, so you type .; and the bootstrap is in place. Get out of KSFEDR and back to timesharing DDT by typing quit 8.3. Bringing ITS down using LOCK Now you are done using timesharing, so it is time to take ITS down again. Run the LOCK program by typing: :LOCK LOCK responds (after DDT asks you to log in again): LOCK.154 _ Say you want the system to go down in 5 minutes (you can't ask for it to happen faster) by typing: 5kill LOCK asks: DO YOU REALLY WANT THE SYSTEM TO GO DOWN? since you do, you type "y". ITS now types on the system console: ___002 LOCK SYS DOWN MAIL WRITE 21:07:36 because your LOCK job is writing the file SYS;DOWN MAIL to contain an explanation of why the system is going down. LOCK will then demand: PLEASE ENTER A BRIEF MESSAGE TO USERS, ENDED BY ^C Since you are the only user, you hardly need to be considerate, so you might as well immediately type a ^C. All kind of things now start happening: Timesharing DDT types on your terminal: PM ITS going down in 4:59 because it thinks you might want to know about this. ITS types on the system console: CULPRIT = ___002 LOCK 21:07:40 to tattle about who took the system down. Then, because nobody is logged in, ITS decides it is OK to go down immediately. (DDT kept telling you to log in, but you wouldn't listen!) It types: PM ITS 1585 NOT IN OPERATION 21:07:41 Then, the system demon named "PFTHMG DRAGON", who performs various accounting functions and therefore has special dispensation to run after the system is officially down, finishes up: PFTHMG DRAGON CHANNA _DRGN_ TIMES WRITE 21:07:42 PFTHMG DRAGON CHANNA LOGOUT TIMES DELRNM 21:07:42 And finally ITS types: SHUTDOWN COMPLETE PI LEVEL 7 BUG YOU ARE NOW IN DDT. BUGPC/ CAIA COFFI4+1 $Q-2/ JRST COFFI7 and returns you to Exec DDT. Don't worry about the use of the word "BUG" in this message, there is no problem. 9. Installing the front end filesystem Now you want to run the FESET routine in the salvager. You could use the Salvager boot tape to get back to the salvager, but now that you have DSKDMP in place it is more convenient to use it to create an executable Salvager. (The Salvager merged in with the ITS binary currently in memory doesn't have any of its symbols loaded into DDT, so it's kind of inconvenient to use.) Start by returning to DSKDMP by typing: $U DSKDMP announces itself: DSKDMP Tell it: L$DDT to get a fresh copy of Exec DDT, then T$SALV BIN to load the file .;SALV BIN, give its symbols to DDT and start DDT. Now you can run the FESET routine by typing: FESET$G The Salvager will ask you: Set FE filesystem directory pointer on the pack on unit # to which you should respond by typing the number of the drive on which your ITS pack is mounted. Remember not to type a carriage return, as the Salvager is only waiting for a single digit. The Salvager now asks: Directory address: You should now type the directory address that KSFEDR told you about above. The FESET routine now returns to DDT. Now return to DSKDMP by typing: $U Since the Salvager currently in memory is a useful tool to have around, you might as well save it as .;@ SALV. Type: D$SALV 10. Bringing up ITS as usual Now you should have a bootable ITS disk pack. To test that it really works, you can try booting it from scratch. First type ^\ to get the 8080 into command mode. Then tell it to boot from the front end filesystem on disk by giving the BT command: BT After a few moments DSKDMP should come up and announce itself in the usual way. Tell DSKDMP to load the file .;@ ITS, and start it in Exec DDT by simply typing that file's name: ITS When DSKDMP indicates it is finished by typing a linefeed, tell DDT to start ITS running by typing: $G And ITS should come up. (You will need to run PDSET again, because the BT command halted the machine.) The file KSHACK;AINOTE > is the notice we keep posted on the front of AI to explain to users about crash dump procedures, etc., you might want to go and read it next. 11. Loading the rest of the filesystem using DUMP Now that ITS is running, you will want to load in system sources and binaries from your distribution tapes. Type ^Z to get a timesharing DDT, and run PDSET to set the time as you did before. Mount the first tape, and start up the DUMP program by typing (to timesharing DDT): :DUMP DUMP will announce itself: DUMP .399 _ The file .INFO.;DUMP INFO documents the commands accepted by the dump program. To load all the files (and links) from a distribution tape into your filesystem tell DUMP: LOAD MERGE NOASK CRDIR ("MERGE" tells DUMP that it should be careful about writing over any file that already exists in your filesystem. "NOASK" tells DUMP that when faced with such a situation, it should always leave the existing file alone. "CRDIR" tells DUMP to create any directories that are needed.) DUMP will want to know which files you want to load from the tape, so it will prompt you: FILE= You respond by typing: *;* * Which means "all the files". Now DUMP will go ahead and start loading. It will type something like: TAPE NO 50 CREATION DATE 860601 After DUMP has read the entire tape, it will prompt you again with: _ Then you can use the command: UNLOAD to rewind and unload the tape. Then mount the next tape and start over with the LOAD command again. If you don't want ITS to type out a line on the system console every time DUMP loads a file into a system directory, patch the system as follows: MNGDIR/ JRST POPJ1 12. Getting started using ITS Congratulations! Now you should have a functional ITS. A good way to get started is to run the INFO program (":INFO" to timesharing DDT). It is pretty much self documenting. Type "H" the first time you run it for a tutorial on its commands. After you understand how to use it, visit the nodes names "INTRO" and "DDT". Then you are on your own. Since we haven't distributed many ITS, I don't know what problems you will run into. Just off the top of my head, here are a few problems that you will probably notice: ITS itself, and all programs that run under ITS assume the machine is located in the time zone for the east coast of the United States. Many programs have the string "MIT" built in to them. A few programs have little tables of the names of other known ITS machines built into them. One of the worst offenders here is the database that finds the name of a users home directory given his user name (binary in INQUIR;DIRS BIN, source in INQUIR;DMUNCH >). Another example is SYS;ATSIGN DEVICE whose source is in SYSENG;@DEV >. MacLisp will not work because it won't recognize the name of your machine. Programs that are built on top of MacLisp won't work either. An adventurous hacker can probably find the place in the MacLisp sources to fix this problem, and assemble a new version. If I ever get around to fixing MacLisp to handle this problem gracefully, I'll certainly send you the fix. I have no idea what you might have to do to get the ITS mail demon (COMSAT) to run and deliver local mail. It may not work to build a COMSAT for a machine with no network interfaces. I haven't been able to get a COMSAT maintainer to sit down and think about the problem of distributing COMSATs to far-away places. Send mail to Bug-COMSAT at AI if you want to complain about this. The INQUIR system, which is a database of all the users who use ITS machines, needs COMSAT to run in order to process changes. Until somebody figures out how to get you a working COMSAT, you are stuck with the database that came on your tape. This database contains all of us here at MIT, but you won't have any way to add yourselves. There are other changes you have to make to get INQUIR run on your machine as well, for example, one part of the INQUIR system is a MacLisp program. I haven't told you anything about how to expand your filesystem to multiple disk packs, or what to do if something seriously bad happens to your filesystem, or what procedures are reasonable for backing up your filesystem on tape. Have fun.