github.com/PDP-10.its
1
0
Fork 0
mirror of https://github.com/PDP-10/its.git synced 2026-01-13 15:27:28 +00:00
Code Issues Releases Wiki Activity
PDP-10.its/doc/kshack/build.doc
Lars Brinkhoff c154af94e2 Move BUILD DOC to its rightful place.
2016-11-01 08:14:28 +01:00

1069 lines
35 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

-*- 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). "<cr>" 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. With this
question the Salvager is asking you what number you want this pack to be.
Your Salvager has been assembled to believe that pack number 0 is your
primary disk pack (you may have other secondary packs someday). Since this
is in fact your primary pack you are trying to build, answer by typing "0"
followed 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<cr>". 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 DX001, 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<cr>
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<cr>
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<cr>
Finally, dump the whole mess out by typing:
D$ITS<cr>
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<cr>
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:
DX ITS 1631 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 (DX)
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:
DX ITS.1631. 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<cr>
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<cr>
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
!
You should cause KSFEDR to create a fresh front end filesystem by typing:
create<cr>
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<cr>
It responds:
Are you sure you want to scribble in the FE filesystem?
You type:
yes<cr>
It asks:
Which file?
You say:
ram<cr>
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
.;<cr>
and the microcode is written. Next you want to write the DSKDMP bootstrap,
so again you say:
write<cr>
It responds:
Are you sure you want to scribble in the FE filesystem?
Again you type:
yes<cr>
When it asks:
Which file?
This time you say:
bt<cr>
And it offers
Input from (Default DSK: USERS3; BT BIN):
which is almost right, you actually want DSK: .; BT BIN, so you type
.;<cr>
and the bootstrap is in place. Get out of KSFEDR and back to timesharing
DDT by typing
quit<cr>
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<cr>
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 kinds of things now start
happening:
Timesharing DDT types on your terminal:
DX 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:
DX ITS 1631 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<cr>
to get a fresh copy of Exec DDT, then
T$SALV BIN<cr>
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<cr>
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<cr>
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<cr>
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<cr>
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<cr>
("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:
*;* *<cr>
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<cr>
to rewind and unload the tape. Then mount the next tape and start over
with the LOAD command again.
Note that the entire set of sources and binarys will probably not fit on a
single RM02 or RM03 disk pack. If you have an RM02 or RM03 system, you
will have to be more selective about what you load.
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<cr>" 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.
Reference in New Issue View Git Blame Copy Permalink