README FOR APPLE MACINTOSH A/UX IRAF VERSION 2.10 Updated 19 June 1993 THE A/UX-IRAF NETWORK DISTRIBUTION This directory and its subdirectories contains the A/UX-IRAF distribution for the Apple Macintosh running A/UX 3.0 or later (the software may run on A/UX 2.x, although this has never been tested). A/UX (Apple's UNIX) is required to run IRAF on the Macintosh; there is no MacOS version of IRAF. README This file. as.aux3.gen AS.AUX3.GEN (all sources) ib.aux3.f2c IB.AUX3.F2C (core system binaries) nb.aux3.f2c NB.AUX3.F2C (NOAO package binaries) auxf77.readme Compilers package for A/UX auxf77.tar.Z Compilers package for A/UX auxbin Miscellaneous utilities for A/UX auxiraf.ms.Z A/UX-IRAF installation guide source auxiraf.ps.Z A/UX-IRAF installation guide Postscript unixsmg.ms.Z UNIX/IRAF Site Manager's Guide source unixsmg.ps.Z UNIX/IRAF Site Manager's Guide Postscript 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 A/UX-IRAF on a Macintosh you need AS.AUX3.GEN and both sets of binaries (IB.AUX3.F2C and NB.AUX3.F2C), plus all the release documentation. If you will be doing any software development in IRAF, including with IMFORT, or you will be installing any IRAF layered packages, you will also need the compilers package. The compilers package includes a Fortran compiler for A/UX. This is discussed in more detail below. ==> NOTE -- Be sure to read the "NOTES" section at the end of this README. ==> This contains various notes we have added as a result of feedback from ==> other users installing this distribution, after it was generated. 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. 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 A/UX 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. o On the local system, create a subdirectory for each distribution file you want to transfer, e.g., ftp> !mkdir as.aux3.gen o Set the current directory on both the local and remote systems. ftp> cd as.aux3.gen ftp> lcd as.aux3.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 A/UX command "sum" will compute the SYS5 checksum of a file. "sum -r" can be used to compute the BSD checksum. 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 INSTALLING A/UX-IRAF Complete instructions for installing and configuring A/UX-IRAF are given in the Macintosh A/UX-IRAF Installation Guide and in the UNIX/IRAF Site Manager's Guide, compressed Postscript versions of which are given in the files auxiraf.ps.Z and unixsmg.ps.Z. On most UNIX networks containing a Postscript printer, a hardcopy version of the manual can be obtained with a command such as % zcat auxiraf.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/stsdas layered package iraf/xray layered package iraf/grasp layered package iraf/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 (or both) pointing to the actual IRAF 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. REQUIRED DISK SPACE The disk space required to fully install A/UX-IRAF (not counting temporary space for the compressed distribution files) is as follows. iraf/iraf 44.9 Mb iraf/irafbin 46.8 Mb f77 package 5.5 Mb The main IRAF source tree (iraf/iraf) can be stripped following the installation to reduce disk space, if desired. Refer to the Site Manager's guide for further information. Any Macintosh that can can run A/UX can run A/UX-IRAF, provided there is adequate space to store the IRAF files. We recommend a IIfx or better system with several hundred Mb of disk and 16-32 Mb of RAM (32 Mb is recommended for A/UX due to the way its SVR2-based kernel uses memory). The minimimum monitor is a 13" or 14" Apple color monitor (640x480), however a higher resolution large screen color monitor is highly recommended for running a window system. COMPILERS PACKAGE The file auxf77.tar.Z, included with the A/UX-IRAF distribution, contains compilers for Fortran and C, as well as a debugger (gdb) which can be used for source or machine code debugging of C, Fortran, or SPP programs. Detailed information on what this package contains, and how to install it, is given in the auxf77.readme file. Note that A/UX comes with a bundled Fortran compiler, "f77"; this should not be used with IRAF, as it is buggy. The "f77" provided in the compiler package should be used instead. The new compilers are installed under the /usr/local directory tree, and do not replace or otherwise affect the default A/UX compilers. Just put /usr/local/bin before /usr/bin in your UNIX search path to use the new compilers. The XC and FC commands in A/UX-IRAF are set up to use the C and Fortran compilers supplied in the compilers package. They will not work with the A/UX compilers. MISCELLANEOUS UTILITIES PACKAGE This package contains a number of executables for various popular unix or X11 utility programs. These are provided on an as-is basis, i.e., we don't want to hear about any problems, as they are either not IRAF programs or are pre-release snapshots of programs still under development. See the README file in the auxbin directory for more information. Note that this directory contains executables for saoimage and xterm, as well as a pre-release version of the IRAF xgterm graphics terminal emulator. The xterm exectuable (generated from MIT X11R4) is included as we have experienced problems with the version of xterm distributed with A/UX. The XmacII executable, also generated from MIT X11R4, is included as the version of XmacII provided with A/UX 3.0 does not work with some third party monitors (I have heard that there is an Apple patch which fixes this as well). GRAPHICS AND IMAGE DISPLAY Even as A/UX-IRAF goes into distribution, we are winding up work on the IRAF X11 support package, which includes much improved facilties for IRAF graphics and image display under the X window system (the pre-release xgterm included in auxbin is from this package). The X11 support package requires V2.10.3 IRAF, due for release in 1993. Until this new software is available, xterm and saoimage should be used to run IRAF run X11. TAPE DRIVE SUPPORT While A/UX 3.0 (and A/UX IRAF) support modern tape devices such as DAT and Exabyte, A/UX does not yet support variable block mode, as is used on most UNIX workstations. The standard tape device in A/UX 3.0 supports only 8K fixed block mode - which is unique to A/UX and incompatible with all UNIX workstations. Hence, tape transfer of data between A/UX and UNIX workstations is currently difficult or impossible. There is a third party tape driver supported by Jim Jagielski at Goddard, available in the archives on jagubox.gsfc.nasa.gov, which also supports 512 byte fixed block mode. This may permit tape transfer with some UNIX workstations (e.g. SGI), however this does not really solve the problem as few workstations support 512 byte fixed block mode. Some UNIX tape drivers allow this mode to be set up as a compile time or runtime default however, so there is a chance that, by building new UNIX kernels for both A/UX and the target UNIX system, one would be able to transfer DAT or Exabyte data tapes. Until this problem is resolved the best approach may be to use tapes only for backing up the system, relying upon network file transfers to move software and data between the A/UX system and UNIX servers. [See also note #4 below] ----------------------------------------------------------------------------- NOTES - (added after the initial distribution was built) 1) If you are inexperienced with A/UX (or even if you are not) we recommend reading the frequently-asked-questions (FAQ) file for A/UX. This is available via anonftp from node jagubox.gsfc.nasa.gov. 2) Some users have had trouble transferring the files to their A/UX system. The simplest way to do this is via ftp but not everyone has access to the internet, or knows how to configure networking on A/UX. Some of the possible methods for file transfer are the following. o ftp under A/UX, Mac on the ethernet. (as on most any UNIX system). o ftp under A/UX, Mac connected via SLIP over a serial connection. This works fine but you have to have a SLIP server to connect to, and you need to know how to set up SLIP and A/UX networking. It is very desirable to get some form of networking connection, either ethernet or SLIP, as a Mac on the internet is much more useful than a mere stand-alone system. o uucp under A/UX. The idea is that you transfer the files via ftp to a local UNIX system, then use uucp over a serial line to transfer to your Mac. This works fine, but requires that you first configure uucp under A/UX. If you are running A/UX 3.0 and you want to use uucp, you should first install the uucp patch available on aux.support.apple.com. o ftp under MacOS. You use a MacOS system to download the files to a Mac file system, then transfer these to A/UX. Here is a recipe for this (thus far untested). - Download the file under MacOS using a binary transfer. - Make sure the MacOS file type is "BIN". If it is anything else, e.g. "TEXT", use ResEdit to change it to "BIN". - In the A/UX finder, drag the file to an A/UX file system. So long as A/UX doesn't think it is a text file, it should not modify the file contents. - In A/UX, use the "fcnvt" utility to convert the file to Apple Double format which will split the MacOS single format file (what you have after the above) into two UNIX files, one with the original file name (foo) and the other with a % prefixed (%foo). The %foo file is the "resource fork" for the file (tells MacOS what type of file it is) and the non-% file is the file data, which should be the compressed unix tar file. Be sure to compare the file checksums with what is in the distribution to verify that the file was correctly transferred. o Mailed distribution. This is awkward for A/UX since there is no standard, widely used medium for transferring large files between A/UX systems, except possibly for CD-ROM. Contact us if all else fails and you want a tape or CD-ROM. (We don't currently make IRAF available for A/UX on CD-ROM, but we may if there is sufficient interest). Try to use the network first, because if you can get things out of the IRAF network archive it will be much easier to get updates. o Small files can be retrieved from the IRAF network archive (or any ftp server) via electronic mail, using publically available gateways available on the net. Don't try to use this for large files such as the main A/UX IRAF distribution files, but it works for modest sized files, including binary files. 3) PROBLEMS WITH TAR. There are a couple of problems with the A/UX "tar" utility which affect the A/UX-IRAF installation. The problems are minor but can lead to problems or confusion for IRAF system managers. IRAF users should not be affected. The problems we have seen are as follows. 1) The IRAF core system and all IRAF layered packages contain a directory bin.generic (the "generic" or machine independent architecture) which is empty by definition. A/UX tar does not recreate this directory. One has to create it manually to install the IRAF system correctly, e.g., after unpacking the as.aux3.gen files, cd $iraf mkdir bin.generic mkdir noao/bin.generic 2) The IRAF multiple architecture support uses a number of symbolic links in $iraf/lib. When the system is configured generic, as is the case when the distribution is made, these links point to nonexistent files. A/UX tar will not write these links to the output tar file if the file does not exist, so the links are not included in the A/UX-IRAF distribution. The links can be recreated manually as follows. cd $iraf/lib ln -s ../bin/libbev.a libbev.a ln -s ../bin/libc.a libc.a ln -s ../bin/libcur.a libcur.a ln -s ../bin/libcurfit.a libcurfit.a ln -s ../bin/libdeboor.a libdeboor.a ln -s ../bin/libds.a libds.a ln -s ../bin/libex.a libex.a ln -s ../bin/libgks.a libgks.a ln -s ../bin/libgkt.a libgkt.a ln -s ../bin/libgsurfit.a libgsurfit.a ln -s ../bin/libimd.a libimd.a ln -s ../bin/libimfort.a libimfort.a ln -s ../bin/libiminterp.a libiminterp.a ln -s ../bin/libinterp.a libinterp.a ln -s ../bin/libllsq.a libllsq.a ln -s ../bin/libmain.o libmain.o ln -s ../bin/libncar.a libncar.a ln -s ../bin/libnlfit.a libnlfit.a ln -s ../bin/libnspp.a libnspp.a ln -s ../bin/libsgi.a libsgi.a ln -s ../bin/libshare.a libshare.a ln -s ../bin/libstg.a libstg.a ln -s ../bin/libsurfit.a libsurfit.a ln -s ../bin/libsys.a libsys.a ln -s ../bin/libvops.a libvops.a ln -s ../bin/libxtools.a libxtools.a IRAF will install and execute correctly without performing these steps, but if you wish to fiddle with the multiple architectures you will need to recreate these links and the bin.generic directory. (If you don't understand what this means, don't worry about it, you won't see the problem). See the UNIX/IRAF Site Manager's Guide for additional information on IRAF multiple architecture support. 4) MORE ON TAPE INTERCHANGE The following prescription for interchanging Exabyte tapes between UNIX (SunOS) and A/UX systems was contributed by Herman Marshall. --- Date: Wed, 17 Nov 1993 09:13:20 -0800 From: eureka@netcom.com (Eureka Scientific) Subject: Reading Exabytes under A/UX (from HLM) To whom it may concern, I finally got the Exabyte attached to my Mac (running A/UX v3.0.2) to read tapes written with an Exabyte drive on a Sun. Here is the prescription. 1) Write the tape on the Sun using a blocking factor of 1k. For example, you can make a tar file and then use dd if=tarfile of=/dev/nrst1 obs=1k You can also use a 2 tape system using dd if you have a tape that needs conversion: dd if=/dev/ ibs=10k of=/dev/ obs=1k I have tried both methods using Exabyte 8200s and found them to work. 2) On the Mac side, get and install Jim Jagielski's new tape driver, tc. It's up to version 31 [3.31]. It's available from jagubox.gsfc.nasa.gov by anonymous ftp. 3) Using prescription in his tc manpage, make a new tape device file using physical blocking. For example, on my system, the Exabyte (model 8205) has SCSI address 1. The non-rewinding tape device is % ls -l /de/rmt/tc1n crw-rw-rw- 1 root sys 23, 9 Oct 24 06:58 tc1n Then (as root) I made a non-rewinding device using % mknod /dev/rmt/phys1n c 23 41 % ls -l /dev/rmt/phys1n crw-rw-rw- 1 root sys 23, 41 Nov 2 00:06 phys1n 4) Read tape under A/UX using dd if=/dev/rmt/phys1n bs=8k | tar -xvof - If I may elaborate, there are several approaches that I tried which failed. In particular, the way I had expected to work (and tried many times with different routines and combinations of ibs and obs before abandonning) was reblocking to 8k and then reading a blocking factor of 8k. I don't know exactly why this one doesn't work but the output is 1k of good data and then 7k of nulls if I used phys1n and the other 7k is just missing if I use tc1n (and the files are a factor of 8 too small). Reading a tape blocked at 1k with dd using ibs=1k also doesnŐt work. The tape drive always hangs when I try to read them with any blocking factor that is not 8k. This whole thing doesn't make much sense to me, so it was *extremely* frustrating. Herman ps. Thanks to all for advice and suggestions.