README FOR DEC ALPHA OSF1/IRAF VERSION 2.10 Current patch level V2.10.4-p2 Revised Thu Jul 11 12:47:06 MST 1996 ----------------------------------------------------------------------------- 6 Jun 1995 Initial V2.10.4 release 13 Sep 1995 patch 1 - see "Patch 1" below 16 Dec 1995 cl.e patch - see "cl.e patch" below 11 Jul 1996 patch 2 - see "Patch 2" below ----------------------------------------------------------------------------- 1. PRELIMINARIES 1.1 THE DEC ALPHA OSF1/IRAF NETWORK DISTRIBUTION This directory and its subdirectories contains the OSF1/IRAF distribution for the DEC Alpha. This distribution is ONLY for the DEC Alpha running OSF/1. The distribution for the DECstation running Ultrix will be found in the DSUX directory under /iraf/v210. The distribution for the VAXstation running Ultrix (VAX cpu) will be found in /iraf/v210/VXUX. The distribution for the VAXstation running VMS will be found in /iraf/v210/VMS5. At this time there is no IRAF release for the DEC Alpha running OpenVMS, although a preliminary version is available from the STSDAS group at STScI. README This file. as.dosf.gen AS.DOSF.GEN (all sources) ib.dosf.alp IB.DOSF.ALP (alpha binaries for core system) nb.dosf.alp NB.DOSF.ALP (alpha binaries for NOAO packages) dosfiraf.ms.Z OSF1/IRAF installation guide source dosfiraf.ps.Z OSF1/IRAF installation guide Postscript unixsmg.ms.Z UNIX/IRAF Site Manager's Guide source unixsmg.ps.Z UNIX/IRAF Site Manager's Guide Postscript patch1.tar.Z V2.10.4 patch 1 patch2.tar.Z V2.10.4 patch 2 cl.e Experimental patched cl.e (see below) (superceded by patch 2) Additional release related documentation of interest. iraf/v210/v210revs.ms.Z V2.10 revisions summary source iraf/v210/v210revs.ps.Z V2.10 revisions summary in postscript iraf/v210/pkgnotes.v210.Z V2.10 package revisions notes iraf/v210/sysnotes.v210.Z V2.10 system revisions notes See also iraf/docs for general documentation. To install OSF1/IRAF on a DEC Alpha you need AS.DOSF.GEN and both the IB and NB binaries, plus all the release documentation. This distribution was prepared on a DEC Alpha system running OSF/1 V2.0 (Rev. 240). We have OSF/1 V3.0 in house but have not yet installed it, preferring to get the initial release of OSF1/IRAF out before upgrading (also it is not clear if we have enough disk space currently to upgrade). We will upgrade to OSF/1 V3.0 and test OSF1/IRAF against it later this year. 1.2 TRANSFERRING THE FILES Each distribution file is stored in a subdirectory containing the compressed and split distribution file, a CHECKSUMS file, and a FILES.Z file. The distribution file is a UNIX TAR file containing one or more directory trees from the IRAF system. To facilitate transfers over unreliable network connections, the distribution file is split into a number of smaller (512 Kb) files. The files can be transferred as follows. These examples are for the OSF/1 version of FTP. o If you did not start up FTP as "ftp -i", exit and restart it with the "-i" switch. This is necessary to be able to do bulk transfers without having to answer annoying and unnecessary yes or no queries for each individual file (alternatively you can type "prompt" after entering ftp to toggle interactive queries). o On the local system, create a subdirectory for each distribution file you want to transfer, e.g., ftp> !mkdir as.dosf.gen o Set the current directory on both the local and remote systems. ftp> cd as.dosf.gen ftp> lcd as.dosf.gen o Transfer all the files in the distribution file directory. A binary transfer is required for the compressed tar files, and will work for the text files as well since both systems are UNIX. ftp> binary ftp> mget * If problems are encountered, use the CHECKSUMS file to verify that any subfiles already transferred are correct. Delete any partially transferred subfiles and restart the transfer (by subfile we mean the 512 Kb files with extensions .00, .01, .02 etc. files making up the distribution file). Both BSD and SYS5 checksums are given. The OSF/1 command "sum" will compute the BSD checksum of a file. Once all the files have been transferred the subfiles can be concatenated and uncompressed to reconstruct the original distribution TAR file, e.g.: % cat as.* | uncompress | tar -tvf - would list the contents of the distribution file. Such a listing is provided in the file FILES.Z in each distribution file directory. An easy way to look at a compressed text file such as FILES.Z is with "zcat": % zcat FILES.Z | page 2. INSTALLING OSF1/IRAF Complete instructions for installing and configuring OSF1/IRAF are given in the DEC Alpha OSF1/IRAF Installation Guide and in the UNIX/IRAF Site Manager's Guide, compressed Postscript versions of which are given in the files dosfiraf.ps.Z and unixsmg.ps.Z. On most local networks containing a Postscript printer, a hardcopy version of the manual can be obtained with a command such as % zcat dosfiraf.ps.Z | lpr [-P] where is the name of the local printer device you want the manual to be printed on. Troff source for the manuals is also provided for sites that do not have ready access to a Postscript printer or for those who want to read the manuals online with nroff. The IRAF sources and binaries, and the IRAF layered packages are distributed as separate modules that can be installed anywhere. However, the following directory structure is recommended to help organize all IRAF related files. Adhering to this directory structure will simplify the installation as well as future upgrades. iraf/iraf core iraf system iraf/iraf/local iraf system manager login dir iraf/irafbin binaries for main iraf release iraf/irafbin/bin. core iraf bin directory iraf/irafbin/noao.bin. noao package bin directory (other binaries) iraf/extern/stsdas layered package iraf/extern/xray layered package iraf/extern/grasp layered package iraf/extern/ice layered package (other layered packages) The location of the root directory "iraf" above is arbitrary, although to avoid possible filename truncation problems it is recommended that the path be kept reasonably short. A good practice is to set up a symbolic link such as /iraf or /usr/iraf pointing to the actual root directory, and use this in all external references to the iraf files, to allow the root directory to be relocated without affecting software that knows the path to the iraf root. This is especially important when iraf is installed in a central location and NFS mounted on a number of client machines. Any of the directories above can be symbolic links pointing to the actual location of the directory, if disk space becomes tight and it is necessary to move something. Please read the installation guide for detailed instructions regarding the installation. 2.1 Patch 1 (13 September 1995) Case 1: You already have the V2.10.4 system installed and you want to install the patch. Unpack patch1.tar.Z at the iraf root and upgrade the BINs. The DOSF version of patch1 includes the HSI tape allocation task alloc.e which is normally owned by root, so to fully install the patch you should delete the old file first and then run the install script afterward as root. % cd $iraf % rm -f unix/bin.alpha/alloc.e % zcat patch1.tar.Z | tar -xpf - % cd $iraf/unix/hlib % su # ./install To upgrading the BINs download the new IB and NB distributions and reinstall the BINs as if you were installing for the first time. Patch 1 does not modify any site dependent files, other than the motd (to update the version information). You can install the patch file without concern that site dependent files such as the DEV files may be modified. Case 2: You are installing V2.10.4 from scratch. Just do a normal install, all of the distribution files have been regenerated to include patch1. You can ignore the patch1.tar.Z file, this is only used to upgraded older installations. 2.2 cl.e patch (16 December 1996) The "cl.e" file is a replacement for $iraf/bin.alpha/cl.e. This fixes bugs related to CL arrays and also adds a new d_trace instruction tracing command. ** This patch is superceded by patch-2 below; do not install cl.e if you ** are installing patch-2. 2.3 Patch 2 (11 July 1996) Patch 2 for DOSF/IRAF is a bug fix upgrade. On some other platforms it includes support for platform upgrades, but our DEC Alpha OSF/1 system has not been upgraded for some time; we are still running V2.0. An upgrade to either OSF V3.X or Digital Unix 4 (depending on what we have in hand at the time) is planned for later this year. To install the patch: Case 1: You already have the V2.10.4 system installed and you want to install the patch. o Install patch 1 first, as outlined above, if you have not already done so. Patch 2 does not include patch 1. o Install patch 2 as outlined below, by untarring the patch file in the IRAF root directory (DO NOT install the cl.e patch). o Replace the core and NOAO bin directories by downloading and installing the IB and NB distributions. To install the patch2.tar.Z: % cd $iraf % zcat patch2.tar.Z | tar -xpf - You do not need to rerun the install script for patch-2, although there is no harm in doing so. Patch-2 does not modify any site dependent config files. To upgrading the BINs download the new IB and NB distributions and reinstall the BINs as if you were installing for the first time. Case 2: You are installing V2.10.4 from scratch. Just do a normal install, all of the distribution files have been regenerated to include patch1. You can ignore the patch1.tar.Z file, this is only used to upgraded older installations. 2.3 REGISTERING YOUR SITE Please register with us if you use IRAF, so that we can track use of IRAF by the community. This also gets you on the IRAF mailing list so that you will receive the IRAF newsletters and other IRAF relating mailings. To register, fill out the form in the v210/REGISTER file and email it to iraf-requests@noao.edu. *** You can also now register via the online IRAF Web pages at http://iraf.noao.edu/register.html (and try out one of those neat Web forms at the same time!) *** 3. A FEW RELATED ITEMS 3.1 SHARED LIBRARIES UNDER OSF/1 By default OSF1/IRAF uses a shared library for most of the IRAF system code. In a normal IRAF installation this should be completely transparent to the IRAF user. Only if IRAF is installed in an unusual way should it be necessary to know about the shared library. The IRAF shared library for OSF1/IRAF is the file "libiraf.so" in the main IRAF bin directory ($iraf/bin.alpha). When the IRAF install script is run the script creates a link to this library in (by default) /usr/local/lib. The runtime loader (see "man loader") in OSF/1 checks this directory by default when searching for shared libraries, so no additional steps are necessary to use the IRAF shared library in the default installation. If for some reason it is necessary to install the IRAF shared library in a nonstandard place you can still run IRAF, but it may be necessary for each user to define LD_LIBRARY_PATH in their Unix environment, including the directory containing libiraf.so in the library search path. This technique can also be used if there are multiple versions of libiraf.so and one wishes to specify the version to be used. 3.2 GRAPHICS AND IMAGE DISPLAY OSF1/IRAF (and IRAF in general) does not include builtin host level programs for graphics and image display. These are available, but are distributed separately from the main IRAF system so that they may be revised and updated on a different schedule (also there are various alternative graphics and display programs which can be used interchangeably with IRAF). When installing IRAF you should also obtain and install the X11 client applications you wish to use for IRAF graphics and image display. We recommend the X11IRAF package available from the /pub/v2103-beta directory in the IRAF network archives. Prebuilt binaries for OSF/1 are included for xgterm and ximtool. An OSF/1 binary for SAOimage can be found in /contrib. The IRAF account login directory ($iraf/local) contains working examples of a console login for IRAF running on the Alpha. In particular note the Mwm*keyboardFocusPolicy: pointer in the .Xdefaults file. This sets "focus follows pointer" and is strongly recommended for use with the X11IRAF clients xgterm and ximtool, which will by default warp the pointer into the window when a cursor read is initiated. The sample .xession file provided shows an example of how to start xgterm and ximtool up automatically at login time. In the configuration shown ximtool has the fifos and the Internet socket disabled, allowing multiple users to use ximtool on the same host without conflict using Unix domain sockets. See the UNIX/IRAF Site Manager's Guide for a more complete overview of IRAF graphics and image display under X11. See also the notes under "things to watch out for" below. 3.3 MAGTAPE INTERFACE Magtape devices are interfaced to IRAF by editing the file dev$tapecap. The default version of this file distributed with OSF1/IRAF contains an example (see "LYRA" at the top of the file) showing a DAT drive on SCSI unit zero. Under "Unit assignments" generic device entries will be found for DAT drives on SCSI units zero and 1, with and without compression. Entries for other devices are easily added. 4. THINGS TO WATCH OUT FOR (IRAF) In general V2.10.4 is very similar to V2.10.3. We did this intentionally since this release is mostly to fix bugs and provide system support for new operating systems or compilers. Major new applications or serious changes to existing applications are being saved for the V2.11 release. An exception is the syntax of the "set node = blah" syntax, used to enable remote image display under IRAF networking. The new syntax introduced in this release requires that an exclamation be appended to the node name, e.g. cl> set node = "blah!" There have also been some changes to the calling sequences of various IRAF tasks: parameter have been added or removed, and so on. Any change like this can break a user script which calls such a task. For a summary of changes to the calling sequences of IRAF tasks see the adass.iraf.announce newsgroup or contact IRAF site support (the adass newsgroups area available directly from iraf.noao.edu via NNTP, via the IRAF Web server, or via email subscription, if your site doesn't carry them locally). 4.1 THINGS TO WATCH OUT FOR (X11) A few things to watch out for if you use IRAF with the new X11IRAF utilities. The point here is to mention briefly some of the more common problems or points of confusion people can run into. o Rule number zero is: you must install these applications before you can use them. They are not automatically installed by IRAF as the x11iraf programs are not really part of IRAF per se. The x11iraf applications are conventional X programs that must be installed in your unix X environment like other X programs. Ximtool and xtapemon are standalone and will run with only the executable installed. Xgterm currently requires that the app-defaults file also be installed. An ximtool option is to install the extended colormap directory in /usr/local/lib/imtoolcmap; this will give you more colormaps to work with in ximtool, and a place to easily add your own colormaps. o When using xgterm, be sure you have done an "stty xgterm" first! You can run IRAF under xgterm with stty set to xterm or gterm, but various capabilities will be lost. If plots come up white on black instead of in color, this probably means that you have stty set to xterm. ==> When xgterm is used correctly with V2.10.4, you should get nice colored plots on a color workstation. A black and white plot probably indicates an stty problem. <== o You should have "focus follows mouse" enabled when using the x11iraf programs, because they warp the cursor in and out of windows when entering and exiting cursor mode. For example when using imexamine the cursor is warped into the graphics or image window when you request a graphics or image cursor. If you do not have focus-follows-mouse enabled this can be very confusing. o Be warned that ximtool is NOT saoimage. The SAOimage command line arguments are not recognized by ximtool. In particular, if you are running multiple ximtools on the same workstation, the procedure for doing this is different with ximtool than it is with SAOimage. For example, while ximtool still supports fifos for client-server communications, it also supports two types of sockets and it will listen on all three types of ports for client connections. To run multiple ximtools on a single host you can still set up private fifos and a private graphcap, however with ximtool it is preferable to use sockets, and the private graphcap is no longer needed. For a more complete description of the ximtool client-server i/o system refer to the ximtool.info file available with the program. Further information is available online in the adass.iraf newsgroups, in the IRAF FAQ, or by sending mail to iraf@noao.edu. o Ximtool uses a private colortable to ensure that there are enough colors to display an image. In some circumstances you may see colors change in the displayed image, or in other windows on the same screen, as the mouse is moved in and out of the ximtool image window. This is normal and happens because most workstations can only display a maximum of 256 colors simultaneously on the workstation screen (this is a hardware limitation). Ximtool goes to some trouble to avoid this color flashing and you can avoid the problem by avoiding using ximtool simultaneously with other applications that use a lot of colors, e.g. mosaic, xv, saoimage, and so on. Refer to the ximtool.info file for a more complete discussion of this problem. o Although the image device interface in V2.10.4 will work with any image display server (imtool, ximtool, saoimage, etc.) there is a limitation currently when trying to display remotely to an older version of IRAF. That is, if you run the display task in V2.10.4 and try to display to a remote host that is running an earlier version of IRAF, it won't work. You can workaround this using a private graphcap (or by adding entries to your standard graphcap), if it should be a problem. Contact the IRAF group for details if this is a problem at your site. Don't be scared off by these caveats; basic usage of the new X11 programs is for the most part straightforward and intuitive. ----------------------------------------------------------------------------- POST-RELEASE NOTES 1. Install script problem > It's been called to our attention that in the newly released Dec > Alpha OSF/1 port the install script attempts to create the default /dev > fifo pipes by referencing the 'mknod' system task in the wrong place (it > tries to find it in /etc/mknod, but under OSF/1 it's in /usr/sbin/mknod). > This means that the fifo pipes won't be installed correctly but XImtool > users probably won't notice the difference. Starting with V2.10.3 IRAF > defaults to using domain sockets based on the userid for image display, > if this fails the /dev fifo pipes are tried (inet pipes are also supported > but aren't usually enabled). XImtool also supports the socket connections > and will listen on all three (domain sockets, fifo pipes, and inet sockets) > ports for a connection so in most cases the /dev pipes won't be needed > unless you use SAOimage as the display server. (June 12, 1995) The simplest way to avoid the above problem is to edit the install script ($iraf/unix/hlib/install) and change /etc/mknod to /usr/sbin/mknod before running or rerunning the script.