.help
NOAO/NSO IRAF/UNIX installation, Nov. 14-15 1985, S. Rooke
.br
A full binary copy of lyra!/iraf (in two tapes) was loaded into the
sunspot! VAX-11/750 running UNIX at NSO. The following notes describe the
various steps taken in the installation.
.nf
1. Leonard Sitongia selected his /u1/ root directory for IRAF as it contained
about 100 Mb in its disk partition.
% mv /u1 /iraf
% vi /etc/fstab # replace "u1" with "iraf" for ra1d
% mount /iraf
% vi /etc/group # add IRAF group members so we can see who
# owns the various IRAF files
% vipw # yanked IRAF group members' entries from
# /etc/passwd/aquila
Now have /iraf with 100000 bytes available; IRAF developers have accounts
for the duration of the installation, mainly so we can easily look at
file ownerships.
2. Read the two tapes into /iraf.
% cd /iraf
% tar -xpf /dev/rmt0 # 1st tape contains /iraf... minus sys/*
(load second tape)
% mkdir /iraf/sys
% cd sys
% tar xp
TAPE READ ERROR AFTER libsys.a
tu0: hard error bn25780 mbsr=13080 <ATTN, DTCMP, DTABT, MBEXC>
cr=100 <INCUPE>
ds=54640 <ERR, MOL, WRL, DPR, DRY, PES>
3. At this point we looked at the tar listing, and saw that the only files
that didn't make it were the following six:
Mkpkg.sh
libcur.a
libmain.o
libstg.a
prelink.e
zzsetenv.def
Not realizing immediately that the 2 libraries must have been development
ones (the real ones were already in /iraf/lib), we attempted to bring
them across from Tucson using TIP(xmodem).
% vi /etc/remote # set Tucson baud rate (1200) for Robotics modem
% tip us-0 # (U.S. Robotics modem looks in /etc/remote)
(now talking to modem)
atdp 1,602,3259251
(got message from micom at remote, in Tucson)
(had to request class "102" rather than class "2").
2% xmodem -sb filename <cr>
(got xmodem message)
~? # to get help from sunspot! tip; look for
# "receive xmodem binary"
~( # (got prompt for local file name)
Thus we copied the 2 libraries and Mkpkg.sh over (we would rebuild the
other files from files already present). We also brought over some files
from lyra!/u2/rooke... for working on graphcap and stdgraph.
4. We now have almost the full binary IRAF under root directory /iraf/.
Now proceed to set up links outside the /iraf/ directories into a few
critical files within it so that all users can access them from a unix
shell.
% su
% cd /usr/include
% ln -s $iraf/lib/libc/iraf.h iraf.h
% cd /local/bin
% ln -s $iraf/lib/mkiraf.csh mkiraf
% ln -s $iraf/lib/cl.e cl
% ln -s $iraf/lib/mklib.e mklib
% ln -s $iraf/lib/xc.e xc
5. We now configure the magtape device tables and give the KI a real host
name then do a "sysgen".
% vi /iraf/dev/hosts # create entries for "sunspot!" and "penumbra!"
% vi /iraf/lib/libc/kernel.h # find "TAPEDRIVE_TABLE"; enter correct
# magtape devices for sunspot!
% su
% cd /iraf/sys
% make >& spool &
(inspecting the spool file found a phase error on envscan.o
from ranlib: libsys.a; mangled string table.
% cd /iraf/sys/etc
% rm envscan.o
% touch envscan.x
% cd ..
% make >& spool & # this time it was OK.
We have now completed the sysgen; however, there had been a minor stdgraph
kernel bug which was removed in a development version of stg_encode I had
tip'd over; I replaced /iraf/sys/gio/stdgraph/stgencode.x and rebuilt the
stdgraph kernel manually:
% cd /iraf/sys/gio/stdgraph
% make >& spool &
(Make wouldn't work; it turned out there was a spurious SPACE
character in the Makefile: "make lib" rather than "makelib" on
the "all: " line; fixed this and rebuilt.)
6. By analogy with the Johns Hopkins installation, since the system
libraries had been modified, I went ahead with relinking the applications
packages; furthermore, I had a development version of showcap which I
used to replace /iraf/pkg/plot/tshowcap.x with in order to debug the
vt240 graphcap entries later on.
% su
% cd /iraf
% csh -x Mkpkg.sh >& spool &
However, talking with Doug Tody during this relink, I found out we only
needed to rebuild the DATAIO package. To save time, I killed the relink,
observed that it had been in the middle of the IMAGES package, and
manually completed the IMAGES rebuild:
% cd /iraf/pkg/images
% make >& spool &
(DATAIO had already successfully built, along with several others. I made
sure that the PLOT package had built successfully with the showcap
change.)
7. All compile-time operations are now complete; we need only modify the
run-time environment for terminal and graphcap entries and set up for
local "mkiraf"'s.
% cd /iraf/dev
% vi termcap # provide vt240 entry
% vi graphcap # provide vt240 entry; this was yanked from
# my development ReGIS graphcap file which
# I had previously "tip"'d over.
% cd /iraf/lib
% vi mkiraf.csh # setenv users /u2/compsup/mother/irafusers
# and directory names at the bottom (prob. no
# changes in these); changed 2 lines about
# vt100 vs vt640 to vt240 vs some other term.
% vi clpackage.cl # change default device names, version, site:
set printer = "imagen" --> "tp"
set stdgraph = "vt640" --> "vt240"
set stdimage = "iism70" --> "? (I forget)"
set stdplot = "versatec" --> "tp"
set terminal = "vt100" --> "vt240"
set version = "NOAO/IRAF V2.0" --> "NOAO/NSO/IRAF V2.0"
% vi login.cl # uncommented printer, stdimage, stdplot and
# gave them the local names.
We also "bgrep"'d some zzsetenv.def files to make sure they weren't
pointing to Tucson pathnames.
8. This completed the non-graphics part of the installation. We were now able
to bring up the cl successfully:
% cd (user's main iraf directory)
% mkiraf
% vi login.cl # modify as desired
% cl
9. The remainder of the installation involved setting up a workable ReGIS
graphcap for NSO's vt240's. I copied the development graphcap entry I
had previously created for the ENCORE HostStation100, and went through
the vt240 Programmer's Summary capability by capability. There were
about six changes from the hs100. Graphics output then worked correctly,
but we had the same problem reading the cursor that I had had with the
hs100 in Tucson. It turned out later, back in Tucson, that the problem
was that I was directing the cl to "lib$xstdgraph.e" (the "kf" parameter)
in graphcap, rather than to "cl" itself. The precedence for the cl
process, when it receives a read-cursor request, is to take the kernel
name from the graphcap entry, regardless of the fact that the cl (or
any other process) was linked directly with the stdgraph kernel code
and calls gki_inline_kernel(). Thus the "kf" parameter in graphcap
must point to the cl itself in order to use the inline kernel. At
present, cursor readback does not work with an external kernel.
Several days after the installation (Nov. 20) I called the "kf" change
in to Leonard at NSO. He made the change and checked out "implot" and
"=gcur", and said they worked correctly with no further changes to our
ReGIS graphcap.
