VMS/IRAF V2.10 System prepared on VMS 5.4 This file last updated 23 June 1993 VMS/IRAF NETWORK DISTRIBUTION This directory, and the subdirectory ia.vms5.vax, contains all the files needed to install VMS/IRAF. README This file ia.vms5.vax Subdirectory containing the VMS/IRAF distribution vmsiraf.ms.Z Source for VMS/IRAF installation guide vmsiraf.ps.Z Postscript version of VMS/IRAF installation guide 0readme VMS-friendly links for the above files ia_vms5_vax or directories. vmsiraf_ms_z vmsiraf_ps_z WHATS NEW IN V2.10 For a complete description of all the changes to VMS/IRAF for V2.10 refer to the updated VMS/IRAF Installation Guide, and to the system notes files "notes.vms" which you will find in the [IRAF.LOCAL] directory once IRAF has been installed. The IRAF Version 2.10 Revisions Summary (v210revs.ps.Z) contains a complete summary of the platform-independent changes to IRAF itself. The changes to VMS/IRAF for V2.10 include major enhancements to the magtape i/o system and IRAF networking. The magtape i/o system now supports a variety of tape drives including 9 track tape, cartridge tape, DAT, and Exabyte. Tape allocation is optional. On systems that support TCP/IP networking a socket based tape status monitor is supported. Given the necessary networking support a VMS tapedrive can be accessed from a remote UNIX host. The networking system includes support for both TCP/IP and DECNET in the IRAF kernel, with runtime selection of the protocol to be used. Support for Multinet for incoming TCP/IP connections is provided, e.g., from the Internet and UNIX hosts. A VMS node running Multinet can be used as a gateway between the Internet (TCP/IP) and the local VMS cluster running DECNET. For outgoing connections (IRAF running on VMS calling IRAF running on a remote UNIX system) most any TCP/IP networking product can be used since for outgoing connects VMS/IRAF networking with the TCP/IP protocol is fully QIO based and requires no other local services. VMS proxy logins are supported and can be used to eliminate password prompts for local connects. Refer to the VMS/IRAF Installation and Site Manager's Guide and the VMS/IRAF system notes file for more detailed information on these facilities. REGISTERING YOUR SITE Please register your site if you use IRAF. This takes only a moment; all you need do is fill out the form in the v210/REGISTER file and mail it to iraf-requests@noao.edu. As an added benefit you will get on the IRAF mailing list, and will receive the IRAF Newsletter and other IRAF mail. RECONSTRUCTING THE BACKUP SAVE SET The subdirectory ia.vms5.vms (ia_vms5_vms) contains the network version of the distribution file IA.VMS5.VAX. This single file contains the entire VMS/IRAF distribution, including both sources and binaries. The file IA.VMS5.VAX is stored in this directory as a compressed VMS BACKUP save file, split into 512 Kb segments. A full listing of the save set is given in the file 0files_z in the archive directory. This listing can be examined with a command such as "zcat < 0files_z | page" on the local UNIX system, after transferring the file. For compatibity with VMS filenaming conventions, the split files in this directory use underscore rather than "." to delimit the filename fields, and the split file names are case insensitive. VMS versions of UNCOMPRESS and SUM (for computing the file checksums) are provided in the subdirectory "util" in the iraf network archive. There are various ways in which the VMS BACKUP file can be reconstructed on disk on the VMS system and used for the IRAF install. Two possible approaches are outlined below, one using an intermediate local UNIX system to reconstruct the file, the other doing everything on the VMS system. UNIX FTP To restore the BACKUP file to disk on the VMS system, using a UNIX system to do the file transfer and uncompress, you need to do the following: 1) Copy the contents of this directory to a local UNIX system. You can also ftp to a VMS system if the VMS system supports it, but these examples will assume you are copying to a UNIX system. If you copy to a VMS system you will need a VMS version of the UNIX "uncompress" program to recover the BACKUP. o If you did not start FTP as "ftp -i", exit and restart it this way. o Create an ia_vms5_vax directory on the local system and go there. From ftp in the v210/VMS5 directory: ftp> cd ia_vms5_vax ftp> lcd ia_vms_vax o Copy all the files: ftp> binary ftp> mget * The compressed archive files total about 46 Mb, so this will take a while. If there are any problems, use the 0checksums file to verify that the files have been transferred correctly. o Reconstruct the original uncompressed VMS BACKUP file: % cat ia_* | uncompress > v210.bck The uncompressed version of the file is about 65 Mb so make sure you have enough disk space, and avoid using NFS or other network file services if at all possible (you can use rsh/remsh if you have to go to a remote disk). 2) Transfer the uncompressed VMS BACKUP file to a VMS disk using FTP, magtape, or whatever you have locally for file transfers between your UNIX and VMS systems. The VMS/BACKUP disk saveset in the distribution has a 32256 byte logical record size (see 0files_z to verify the actual block size), so if your FTP utility allows you to set the block size of the output binary file, do so. 3) Do a DIR/FULL on the transferred v210.bck file to verify that the block size is set to 32256. If this is not the case, you can reblock the file with the following commands: $ create/fdl=sys$input v210.temp record carriage_control none size 32256 format fixed $ copy v210.bck v210.temp/overlay $ rename v210.temp v210.bck VMS FTP To do everything directly on the VMS system you will need both a VMS version of FTP connected to the internet, and the VMS version of the COMPRESS and UNCOMPRESS utilities, a copy of which is stored in the "util" subdirectory of the IRAF network archive on iraf.noao.edu. From the iraf.noao.edu:/util directory: -rw-r--r-- 1 tody 1061 Jun 20 1990 README -rw-r--r-- 1 tody 90112 Apr 23 1990 compress.tar -rwxr-xr-x 1 tody 84480 Jun 28 1990 compress_vms.exe -rw-r--r-- 1 tody 92160 Jun 28 1990 compress_vms.tar -rw-r--r-- 1 tody 940 May 11 1990 sum.c -rw-r--r-- 1 tody 73728 Jun 28 1990 sum_vms.exe The executables are old but are statically linked, and so far as we know at this point still work. To reconstruct the BACKUP format distribution file using VMS: o Transfer the files with VMS FTP. The commands required to do this depend upon what version of FTP is used, but most versions provide something similar to the MGET command described above. o Transfer the VMS COMPRESS executable as well. Define the following VMS symbols so that you will be able to run UNCOMPRESS as a DCL foreign task. $ compress :== "$disk:[dir]compress_vms.exe compress" $ uncompress :== "$disk:[dir]compress_vms.exe uncompress" where "disk:[dir]compress_vms.exe" is replaced by the actual disk and filenames used to access the compress executable on your system. o Concatenate the split files to produce one large compressed file. $ copy/concatenate ia_vms5_vax_z.* v210.bck_z o Use UNCOMPRESS to uncompress the file. We do this using the "-c" option of VMS UNCOMPRESS to concatenate the uncompressed output to an existing zero length file, in order to get the file type and record size needed for the VMS BACKUP save set. $ create/fdl=sys$input v210.bck record carriage_control none size 32256 format fixed $ uncompress -s 45545624 -c v210.bck v210.bck_z Here, 45545624 is the size in bytes of the compressed data sequence, i.e., for the V2.10 distribution, 88 * 512000 + 489624, where the first 88 split files are 512000 bytes each and the last partial one is 489624. On VMS, it is necessary to specify explicitly the number of bytes to be uncompressed as many VMS file operations (such as the copy/concat) will round the file size out to an integral number of file blocks. You should check these numbers as the actual distribution size may differ from what is written here. Obviously, when decompressing a different file (such as a patch file) the size in bytes of the compressed sequence will differ. You should then be able to use BACKUP to access the v210.bck file as a VMS BACKUP save set. VMS DECNET When accessing the IRAF network archive from a VMS host, bear in mind that the network archive is on a UNIX system. Since you are talking to a UNIX host you may need to use a different syntax to copy over files in the archive that have non-standard VMS names or are capitalized. For the most part we have tried to avoid the need for this by using file names (or adding links) that can be read directly on VMS systems. Examples of a couple simple file transfers follow. $ copy/log 5362::"/u1/ftp/iraf/v210/vms5/0readme" 0readme $ copy/log 5362::"/u1/ftp/iraf/v210/vms5/vmsiraf_ps_z" vmsiraf_ps_z In the second example we are copying over a compressed file, which will have to be uncompressed before it can be read or printed. A directory may be listed as in the following examples. $ dir 5362::u1:[ftp] $ dir 5362::u1:[ftp.iraf] or $ dir 5362::"/u1/ftp/*" $ dir 5362::"/u1/ftp/iraf/*" To get IRAF V2.10 from the network archive using DECnet directly from a VMS host, perform the following steps. Get the compressed format files: $ copy/log 5362::u1:[ftp.iraf.v210.vms5.ia_vms5_vax]*.* [] This will copy the individual pieces, called ia_vms5_vax_z.00 to .88, over to your machine. If the network transfer fails for any reason, delete the most recent, incomplete piece, and start again with that same piece. If you need to restart the following command can be used to generate a file containing a list of the network files names, which can then be edited to produce a series of commands to copy the needed files. $ dir/out=_copy.com/col=1 5362::u1:[ftp.iraf.v210.vms5.ia_vms5_vax] Get the "sum" and "uncompress" programs: $ copy/log 5362::u1:[ftp.util]sum_vms.exe [] $ copy/log 5362::u1:[ftp.util]compress_vms.exe [] This finishes the more critical network transfers. You can verify the transfers with the "sum" program. Once you are satisfied that the files have been transferred properly they can be concatenated with the following command. $ copy ia_vms5_vax_z.* v210.bck_z You should get an "incompletely copied" error for only the last file, which can be ignored. Errors on any other files are significant. Uncompress the save-set. This takes a lot of CPU time on a VAX, so we recommend submitting a batch job with the following command file (replace the "disk" and "[directory]" by the actual names for your system): $ set default disk:[directory] $ uncompress :== $disk:[directory]compress_vms uncompress $ create/fdl=sys$input v210.bck record carriage_control none size 32256 format fixed $! $ uncompress -s 45545624 -c v210.bck v210.bck_z $ exit See the comments given earlier for an explanation of the -s 45545624 argument, which you should check. Alternatively, you can run these commands on-line, but the time to uncompress the file may be an hour or longer depending upon what model of VAX you are using. In the above you may get one RMS error (INVALID RECORD SIZE), which you can ignore. The file V210.BCK is now a valid VMS 5.2 BACKUP save-set, and can be used to install IRAF. FILE CHECKSUMS If you need to compute file checksums on VMS to verify the file transfers, you will need the checksum program util/sum_vms.exe in the IRAF network archive. After retrieving the file from the archive (be sure to do a binary transfer), define it as a DCL foreign task as follows: $ sum :== "$disk:[dir]sum_vms.exe" where the "disk", "dir", etc. are modified to reflect the actual location of the file on your system. Usage is then very simple: $ sum file [file...] This assumes that the file size in bytes is accurately recorded in the VMS file header. If this is not the case, the "-nb" switch to SUM should be used to specify the maximum number of bytes of data to be used to compute the checksum, e.g., $ sum -nb 454771 file would use only the first 454771 bytes for the checksum. INSTALLING VMS/IRAF Proceed with the installation using the disk save set. Full instructions for the VMS/IRAF installation are given in the VMS/IRAF Installation Guide. A Postscript version of this manual is provided in the file vmsiraf.ps.Z in the archive directory. The installation is identical to that described in the manual, except that BACKUP is run on the disk save set, rather than on a tape file. --------------------------------------------------------------------------- Notes added since the release. 1. Reconstructing the BACKUP save set. Nigel add the following comment. The workarounds for this appear to be: use ftp for the file transfer, or transfer the files to a local unix host and concatenate and uncompress them there (much faster anyway), then transfer the large BACKUP file to the VMS host for the installation. > Date: Fri, 15 Apr 94 14:48:27 MST > From: sharp@vela (Nigel Sharp) > Subject: VMS distribution and instructions > To: iraf@vela > > In a recent build of IRAF V2.10 for VMS, we came across a small hiccup > which may have always been present, but never previously noticed. > Getting VMS/IRAF requires transferring a large number of files, concatenating > them into one, uncompressing that one into a backup save-set, and then > restoring that save-set. If the files are transferred using ftp, then > all of the individual ia_vms5_vax.* files appear on VMS with a file > organisation of "Fixed length 512 byte records", and the subsequent steps > go as described, correctly. However, if you use the alternative DECnet > copy method > $ copy/log 5362::u1:[ftp.iraf.v210.vms5.ia_vms5_vax]*.* [] > > then file ia_vms5_vax.88 ONLY ends up with a record organisation of > "Variable length, maximum 1024 bytes". As a result, the copy command > will not append this last file ("incompatible attributes"), the suggested > uncompress command will complain that it did not handle the specified > number of bytes, and the final save-set is truncated. > > However, since the save-set is perfectly valid, and is truncated in the > [.VMS.X11.SRC] subdirectory, this problem does not preclude a perfectly > functional IRAF installation, and would only be noticed if anyone wanted > to rebuild Xterm2, whose source would mostly be missing. > > I don't know if the error is in the Sun DECnet transfer, or in the way the > file was created and/or stored in the ftp archive, although it is surely > significant that it is the last, smaller-sized, piece that goes wrong. 2. Reading the BACKUP save set From: zirnstein@purvs3.physics.purdue.edu Date: Wed, 28 Jun 1995 14:51:05 -0500 > A comment regarding the file vmsiraf.ps.Z (VMS/IRAF Installation and > Site Manager's Guide): On page 4, section 2.2.1, the command you give for > installing IRAF from the backup save set is > > backup v210.bck/select=[iraf...] [...]/own=iraf/prot=w:r > > This would not work for us without adding the /save_set qualifier; we also > used /log to see that the backup was proceding normally. > > backup v210.bck/save_set/select=[iraf...] [...]/own=iraf/prot=w:r/log