From 40e5a5811c6ffce9b0974e93cdd927cbcf60c157 Mon Sep 17 00:00:00 2001
From: Joe Hunkeler <jhunkeler@gmail.com>
Date: Tue, 11 Aug 2015 16:51:37 -0400
Subject: Repatch (from linux) of OSX IRAF

---
 doc/ports/nsoport.hlp | 193 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 doc/ports/nsoport.hlp

(limited to 'doc/ports/nsoport.hlp')

diff --git a/doc/ports/nsoport.hlp b/doc/ports/nsoport.hlp
new file mode 100644
index 00000000..334471aa
--- /dev/null
+++ b/doc/ports/nsoport.hlp
@@ -0,0 +1,193 @@
+.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.
-- 
cgit 

