                  -------------------------------------
                  * VAX-NIL Installation Instructions *
                  -------------------------------------

                 Last Update: 15-OCT-1982, George Carrette

There are 4 parts to installing VAX-NIL at your site.

1) Restoration of the NIL directory hierarchy from the BACKUP tape.
2) Definition of the required logical names and symbols.
3) Invoking the Lisp dynamic linker.
4) Handling System and User considerations such as setting up
   the proper logical names and symbols (system or group wide
   and/or in user login files), and installing certain images
   for efficiency reasons.


[Step 1]
The entire hierarchy, including executable, object, and source files
in Macro-32, Bliss-32, and Lisp; and including various DCL command
files and sundry data files and documentation comprises 1500 files
and 39 sub-directories, using approximately 25 thousand blocks of disk space.
(This does not presently include a NIL reference manual).
If you have the disk space then restore the whole thing, if not,
then use selective backup of [NIL.PORT], e.g.
$ BACKUP/LOG MTA0:NIL/SELECT=[NIL.PORT]*.*   [*...]
and then select the files according to MINIPORT.COM and VASPORT.COM.

[Step 2]
Define the logical name NIL$DISK so that NIL$DISK:[NIL] will be the
toplevel directory in the NIL hierarchy. Then execute:
$ @NIL$DISK:[NIL.COM]SYM

[Step 3]
If you are running VMS version 3.0, then all you need run now is
the lisp linker:
$ LISPLINK
This will result in a rather verbose display of "loading" messages,
(which will take a couple minutes) after which the message 
"; Suspending Environment" will be printed. Followed after a silent
pause of about 30 seconds by the standard system startup herald.
At this point a read-eval-print loop is entered, where you will
want to type ^Y (control-Y) to exit to DCL level, and then type
$ LXNIL/KILL
The newly created saved lisp enviroment may be restarted by
$ NIL

If you are not running VMS 3.0 then you may have to run the VMS linker,
(in which case you had better have restored the obj files from BACKUP),
$ NLINK
$ SET DEF NIL$DISK:[NIL.FOO]
$ @RNILLINK
Sometimes the RNIL.B32 may need to be recompiled, to do that:
$ BLISS/LIB NILLIB:NILLIB
$ BLISS RNIL
then do the link stuff as above of course.

example: To go from VMS 2.4 to VMS 3.0 we had to do the following:
$ BLISS/LIB NILLIB:NILLIB
$ SET DEF [NIL.FOO]
$ BLISS RNIL
$ @RNILLINK
$ NLINK
$ LISPLINK

[Step 4]
See the file NIL$DISK:[NIL.COM]NILINSTAL.COM, which can be moved
(perhaps edited first) to SYS$MANAGER. Then add this to SYSTARTUP.COM:
$@SYS$MANAGER:NILINSTAL
Then users who want to use NIL must have executed in their login files:
$@NIL$DISK:[NIL.COM]SYM

This will set up the the standard way of calling NIL,
$ NIL
Which will run NIL as a subprocessing. ^Y will exit the subprocess, to resume:
$ NIL
and to kill the subprocess:
$ NIL/KILL

The directory [NIL.SITE] has two files of interest:
[NIL.SITE]SITEPARAMS which if it exists in compiled form will
be loaded right before the LISPLINK saves the virtual memory image.
And [NIL.SITE]DEFAULT.INI, which is loaded at "re-startup" time
if the user does not have a SYS$LOGIN:NIL.INI file.
After NIL is created on your system then you should edit SITEPARAMS
and compile it. The information is noncritical however.

Upon startup NIL will look for the logical-name "TERM" to determine
the type of terminal it is connected to. For example:
$ Define TERM "vt100"
Presently it does all its own cursor positioning using the data in
the file NIL$TERMCAP. If the logical name "TERM" is not defined then
NIL will prompt the user for the info upon startup.

[Optional Verification]
In NIL do:
(LOAD "NIL$DISK:[NIL.VERIFY]VERIFY")
(VERIFY "TEST")
Then sit back and watch the little demonstration. No, we do not have
program verification technology to the point where this gives a proof
of correctness for the NIL. However..., then run
$ DIFFERENCES NIL$DISK:[NIL.VERIFY]TEST.VFY

[What if Failure?]
If you ran out of disk space in step 1, then we can suggest that
you somehow make more space temporarily, (e.g. backup and delete files),
and then prune down to the minimum given in NIL$DISK:[NIL.PORT]MINIPORT.COM
when step 3 is completed.

Step 2 couldn't fail. (We think).

Step 3 could fail if various system generation paramaters and account quotas
are not set high enough. The main thing is that the virtual image will
be about 5 megabytes, and users could need more, so VIRTUALPAGECNT
should be at least 16k pages. If the VMS version is 2.5 then some
files also need to be recompiled.

In step 4, note that the running NIL image is mostly pure, sharable,
code and data, so there is a big performance payoff in proper
installation and SYSGEN tuning on a multi-NIL-user system.
There must be sufficient global sections and pages of course.

[*Help*]
Send net mail to BUG-NIL@MIT-ML. Or US mail to:

Glenn Burke
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, Massachusetts, 02139

[Other Options]
If you want to be able to use the VMS debugger on the running lisp
image then execute the following:
$RUN [NIL.HACKS]SETDEBUG
Giving NIL$DISK:[NIL.EXE]LISP.EXE; as the filename, and answering Y to
the question. With this setting NIL will start up in the VMS debugger,
and you must type GO<CR> to actually start it.
